home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 2_3_01.tro < prev    next >
Text File  |  1991-12-12  |  113KB  |  3,831 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .sp 1P
  23. .ce 1000
  24. \v'12P'
  25. \s12PART\ I
  26. \v'4P'
  27. .RT
  28. .ce 0
  29. .sp 1P
  30. .ce 1000
  31. \fBRecommendations\ E.401\ to\ E.428\fR \v'2P'
  32. .ce 0
  33. .sp 1P
  34. .ce 1000
  35. \fBINTERNATIONAL\ TELEPHONE\ NETWORK\ MANAGEMENT\fR 
  36. .ce 0
  37. .sp 1P
  38. .ce 1000
  39. \fBAND\ CHECKING\ OF\ SERVICE\ QUALITY\fR 
  40. .ce 0
  41. .sp 1P
  42. .LP
  43. .rs
  44. .sp 28P
  45. .LP
  46. .bp
  47. .LP
  48. .rs
  49. .sp 10P
  50. .LP
  51. .EF '%     \ \ \ ^''
  52. .OF ''' \ \ \ ^    %'
  53. .LP
  54. \fBMONTAGE:\ \fR PAGE 2 = PAGE BLANCHE
  55. .sp 1P
  56. .RT
  57. .LP
  58. .bp
  59. .sp 1P
  60. .ce 1000
  61. \v'3P'
  62. SECTION\ 1
  63. .ce 0
  64. .sp 1P
  65. .ce 1000
  66. \fBINTERNATIONAL\ SERVICE\ STATISTICS\fR 
  67. .ce 0
  68. .sp 1P
  69. .sp 2P
  70. .LP
  71. \fBRecommendation\ E.401\fR 
  72. .RT
  73. .sp 2P
  74. .ce 1000
  75. \fBSTATISTICS\ FOR\ THE\ INTERNATIONAL\ TELEPHONE\ SERVICE\fR 
  76. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.401''
  77. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.401    %'
  78. .ce 0
  79. .sp 1P
  80. .ce 1000
  81. \fB(NUMBER\ OF\ CIRCUITS\ IN\ OPERATION\ AND\ VOLUME\ OF\ TRAFFIC)\fR 
  82. .ce 0
  83. .sp 1P
  84. .ce 1000
  85. (Statistics exchanged by Administrations)
  86. .sp 9p
  87. .RT
  88. .ce 0
  89. .sp 1P
  90. .PP
  91. Administrations exchange each year, \fIin February\fR , statistics
  92. showing the number of circuits used and the volume of traffic monitored 
  93. in the preceding year, as well as estimates of the number of circuits which 
  94. will be 
  95. required three years and five years later. These statistics shall be drawn 
  96. up in the form indicated below. 
  97. .sp 1P
  98. .RT
  99. .PP
  100. A copy of the statistics shall be sent to the CCITT Secretariat for information. 
  101. .ce 1000
  102. ANNEX\ A
  103. .ce 0
  104. .ce 1000
  105. (to Recommendation E.401)
  106. .sp 9p
  107. .RT
  108. .ce 0
  109. .ce 1000
  110. \fBHow to fill in the table on international\fR 
  111. \fBtelephone traffic\fR 
  112. \fBstatistics\fR 
  113. .sp 1P
  114. .RT
  115. .ce 0
  116. .LP
  117. Column\ 1
  118.     Designation of the connection by giving the name of the
  119. outgoing exchange first and then the name of the incoming exchange. Two\(hyway
  120. connections will be shown in alphabetical order.
  121. .sp 1P
  122. .RT
  123. .LP
  124. Columns\ 2\ and\ 3
  125.     Number of circuits in operation as on \fI31 December\fR 
  126.  | f the year of the statistics.
  127. .LP
  128. The number will be shown in column\ 2 when it refers to outgoing circuits and
  129. in column\ 3 when it refers to both\(hyway circuits.
  130. .LP
  131. Columns\ 4\ and\ 5
  132.     Number of circuits which would have been required
  133. during the year of the statistics.
  134. .LP
  135. Column\ 6
  136.     Method of operation.
  137. .LP
  138.     The following abbreviations will be used:
  139. .LP
  140.     A
  141.     for automatic,
  142. .LP
  143.     SA
  144.     for semiautomatic,
  145. .LP
  146.     M
  147.     for manual,
  148. .LP
  149.     A\ +\ SA
  150.     for automatic and semiautomatic.
  151. .LP
  152. Column\ 7
  153.     Destination of traffic.
  154. .LP
  155.     Each relation will be shown in this column on a separate line.
  156. .LP
  157.     In the example given, the traffic routed over the
  158. Z\*:urich\(hyK\o"\(*s/"benhavn circuits is destined for Denmark
  159. (terminal), Sweden, Norway and Finland (transit). In
  160. this case, the data for each destination will be shown
  161. in columns,\ 8, 9, 10 and\ 11. The total traffic figure,
  162. however, should not be omitted. These data will be
  163. bracketed together. If the connection handles traffic
  164. only to the country in which the incoming exchange is
  165. situated, only the word \*Qterminal\*U will appear in
  166. column\ 7.
  167. .bp
  168. .LP
  169. Columns\ 8\ and\ 9
  170.     Busy\(hyhour traffic, expressed in
  171. \fIerlangs\fR . (See Recommendation\ E.600.)
  172. .LP
  173.     The traffic measured during the busiest month of the year of the
  174. statistics is given in column\ 9. For two\(hyway circuit
  175. groups the total amount of incoming and outgoing
  176. traffic should be given. In column\ 8 the month of the
  177. year during which the traffic was measured should be
  178. indicated in roman numerals.
  179. .LP
  180. Column\ 10
  181.     Busy hour (UTC).
  182. .LP
  183.     This refers to the busy hour as defined in
  184. Recommendation E.600.
  185. .LP
  186. Column\ 11
  187.     Annual increase, in\ %. Each Administration should insert
  188. in this column the annual traffic increase rate with
  189. respect to the previous year.
  190. .LP
  191. Columns\ 12\ and\ 13
  192.     Columns 12 and 13 should show the estimated number
  193. of circuits required to route traffic in three and five
  194. years' time, respectively. For example, if the statistics
  195. relating to\ 1982 are drawn up in February\ 1983,
  196. column\ 12 will give the estimated number of circuits
  197. required in\ 1986 and column\ 13 those required in\ 1988.
  198. .LP
  199. .rs
  200. .sp 38P
  201. .ad r
  202. \fBTABLEAU, p. 366 (R\*'ecup.) T1.401\fR 
  203. .sp 1P
  204. .RT
  205. .ad b
  206. .RT
  207. .LP
  208. .bp
  209. .sp 1P
  210. .ce 1000
  211. \v'3P'
  212. SECTION\ 2
  213. .ce 0
  214. .sp 1P
  215. .ce 1000
  216. \fBINTERNATIONAL\ NETWORK\ MANAGEMENT\fR 
  217. .ce 0
  218. .sp 1P
  219. .sp 2P
  220. .LP
  221. \fBRecommendation\ E.410\fR 
  222. .RT
  223. .sp 2P
  224. .sp 1P
  225. .ce 1000
  226. \fBINTERNATIONAL\ NETWORK\ MANAGEMENT\ \(em\ GENERAL\ INFORMATION\fR 
  227. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.410''
  228. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.410    %'
  229. .ce 0
  230. .sp 1P
  231. .LP
  232. \fB1\fR     \fBIntroduction\fR 
  233. .sp 1P
  234. .RT
  235. .PP
  236. The demand for international telephone service continues to
  237. increase substantially. This increasing demand has been met by advances 
  238. in both technology and operational techniques. The growth of traffic has 
  239. also required the development of larger transmission systems and exchanges 
  240. to provide the 
  241. capacity to meet the required grade of service. With the continued growth of
  242. the international automatic service, direct supervision and control over
  243. traffic has decreased since operators are no longer involved in establishing
  244. most calls.
  245. .PP
  246. In addition to the above, the introduction of larger digital
  247. transmission and switching systems, along with common channel signalling, 
  248. has resulted in an international telephone network which is highly interconnected 
  249. and interactive, and which has become increasingly vulnerable to overload 
  250. and congestion. This overload and congestion can occur with little or no 
  251. advance 
  252. warning.
  253. .PP
  254. A number of events may arise which can have a serious effect on the
  255. international telephone service. Among these events are:
  256. .RT
  257. .LP
  258.     \(em
  259.     failures of international or national transmission systems;
  260. .LP
  261.     \(em
  262.     failures of international or national exchanges;
  263. .LP
  264.     \(em
  265.     planned outages of transmission systems and exchanges;
  266. .LP
  267.     \(em
  268.     abnormal increases in traffic demand. The events which give
  269. rise to such traffic demand may be foreseen (e.g.,\ national or
  270. religious holidays, international sporting events) or unforeseen
  271. (e.g.,\ natural disasters, political crises);
  272. .LP
  273.     \(em
  274.     focussed overloads, and in particular, mass\(hycalling;
  275. .LP
  276.     \(em
  277.     difficulties in meeting the requirements of international
  278. traffic resulting (for example) from delays in the provision of
  279. additional circuits or equipment;
  280. .LP
  281.     \(em
  282.     congestion in connected networks.
  283. .PP
  284. These events can lead to congestion which, if uncontrolled, may
  285. spread and thus seriously degrade the service in other parts of the
  286. international network.  Considerable benefits can be derived for the
  287. international network as a whole if prompt action is taken to control the
  288. effect on service of such events.
  289. .PP
  290. In addition, as the telephone network migrates toward ISDN,
  291. interworking with other networks will develop. With interworking, failure or
  292. congestion in one network, or in the interface between networks, can have an
  293. adverse impact on the performance of the connected network(s).
  294. .PP
  295. The above considerations have led to the development of \*Qinternational 
  296. network management\*U, which encompasses all the activities necessary to 
  297. reduce the effect on service of any situation affecting unfavourably the 
  298. international telephone network, and in the future, the ISDN.
  299. .PP
  300. \fINote\fR \ \(em\ Much of the guidance on international network management 
  301. may be applicable in national networks. 
  302. .bp
  303. .RT
  304. .sp 2P
  305. .LP
  306. \fB2\fR     \fBDefinition of international network management\fR 
  307. .sp 1P
  308. .RT
  309. .PP
  310. \fBinternational network management\fR is the function of
  311. supervising the international network and taking action when necessary to
  312. control the flow of traffic.
  313. .PP
  314. Network management requires real\(hytime monitoring and measurement of
  315. current network status and performance, and the ability to take prompt 
  316. action to control the flow of traffic. 
  317. .RT
  318. .sp 2P
  319. .LP
  320. \fB3\fR     \fBObjective of network management\fR 
  321. .sp 1P
  322. .RT
  323. .PP
  324. The objective of network management is to enable as many calls as possible 
  325. to be successfully completed. This objective is met by maximizing the use 
  326. of all available equipment and facilities in any situation through the 
  327. application of the principles given below.
  328. .RT
  329. .sp 2P
  330. .LP
  331. \fB4\fR     \fBPrinciples of international network management\fR 
  332. .sp 1P
  333. .RT
  334. .sp 1P
  335. .LP
  336. 4.1
  337.     \fIUtilize all available circuits\fR 
  338. .sp 9p
  339. .RT
  340. .PP
  341. There are periods when, due to changing traffic patterns, the
  342. demand for service cannot be met by the available circuits in the normal
  343. .PP
  344. routing. At the same time, many circuits to other locations may be idle 
  345. due to differences in calling patterns caused by time zones, local calling 
  346. habits, or busy season variations. After negotiation and agreement amongst 
  347. the 
  348. Administrations affected, some or all of the unusually heavy traffic can be
  349. redirected to this idle capacity for completion.
  350. .RT
  351. .sp 1P
  352. .LP
  353. 4.2
  354.      \fIKeep all available circuits filled with traffic\fR \fIwhich has a 
  355. high probability of resulting in effective calls\fR 
  356. .sp 9p
  357. .RT
  358. .PP
  359. The telephone network is generally circuit\(hylimited; therefore the number 
  360. of simultaneous effective calls is strongly influenced by the 
  361. number of available circuits. However, ineffective calls can occupy circuit
  362. capacity which would otherwise be available for effective calls. Therefore
  363. identifying those call attempts which are likely to be ineffective because 
  364. of a situation in the network (e.g.,\ a failure), and reducing them as 
  365. close to 
  366. their source as possible, will allow circuit capacity to be available for 
  367. call attempts which have a higher probability of being effective. 
  368. .RT
  369. .sp 1P
  370. .LP
  371. 4.3
  372.     \fIWhen all available circuits are in use, give priority to calls\fR 
  373. \fIrequiring a minimum number of circuits to form a connection\fR 
  374. .sp 9p
  375. .RT
  376. .PP
  377. When telephone networks are designed using automatic alternate
  378. routing of calls, efficient operation occurs when traffic loads are at 
  379. or below engineered values. However, as traffic loads increase above the 
  380. engineered 
  381. value, the ability of the network to carry effective calls decreases since 
  382. an increased number of calls require two or more circuits to form a connection. 
  383. Such calls increase the possibility of one multi\(hylink call blocking several
  384. potential calls.
  385. .PP
  386. Thus automatic alternate routing should be restricted to give
  387. preference to direct routed traffic during periods of abnormally high
  388. demand.
  389. .RT
  390. .sp 1P
  391. .LP
  392. 4.4
  393.     \fIInhibit\fR 
  394. \fIswitching congestion\fR \fIand prevent its spread\fR 
  395. .sp 9p
  396. .RT
  397. .PP
  398. A large increase in switching attempts can result in switching
  399. congestion when the switching capacity of an exchange is exceeded. If the
  400. switching congestion is left uncontrolled, it can spread to connected exchanges 
  401. or networks and cause a further degradation of network performance. Controls 
  402. should be applied which inhibit switching congestion by removing attempts 
  403. from the congested exchange which have a low chance of resulting in a succesful 
  404. call.
  405. .PP
  406. \fINote\fR \ \(em\ Network management assumes that the network is adequately
  407. engineered to meet the normal levels of traffic, the requirement for which 
  408. is described in Recommendations\ E.171, E.510, E.520, E.522, E.540 and\ 
  409. E.541. 
  410. .bp
  411. .RT
  412. .sp 2P
  413. .LP
  414. \fB5\fR     \fBBenefits derived from international network management\fR 
  415. .sp 1P
  416. .RT
  417. .PP
  418. Among the benefits to be derived from international network
  419. management are:
  420. .RT
  421. .PP
  422. 5.1
  423. Increased revenue which is derived from an increase in
  424. successful calls.
  425. .PP
  426. 5.2
  427. Improved service to the customer. This can lead, in
  428. turn, to:
  429. .LP
  430.     \(em
  431.     improved customer relations;
  432. .LP
  433.     \(em
  434.     stimulation of customer calling rate;
  435. .LP
  436.     \(em
  437.     increased customer acceptance of new services.
  438. .PP
  439. 5.3
  440. More efficient use of the network. This can result in:
  441. .LP
  442.     \(em
  443.     an increased return on the capital invested in the
  444. network;
  445. .LP
  446.     \(em
  447.     an improvement in the ratio of effective to ineffective
  448. calls.
  449. .PP
  450. 5.4
  451. Greater awareness of the actual status and performance of the
  452. network. Such awareness can lead to:
  453. .LP
  454.     \(em
  455.     a basis by which network management and maintenance
  456. priorities can be established;
  457. .LP
  458.     \(em
  459.     improved network planning information;
  460. .LP
  461.     \(em
  462.     improved information on which future capital investment in
  463. the network can be decided;
  464. .LP
  465.     \(em
  466.     improved public relations.
  467. .PP
  468. 5.5
  469. Protection of revenue and important services, particularly
  470. during severe network situations.
  471. .sp 2P
  472. .LP
  473. \fB6\fR     \fBNetwork management functions\fR 
  474. .sp 1P
  475. .RT
  476. .PP
  477. Network management encompasses all of the activities necessary to identify 
  478. conditions which may adversely affect network performance and service to 
  479. the customer, and the application of network controls to minimize their 
  480. impact. This includes the following functions:
  481. .RT
  482. .LP
  483.     a)
  484.     monitoring the status and performance of the
  485. network on a real\(hytime basis, which includes collecting and analyzing
  486. relevant data;
  487. .LP
  488.     b)
  489.     detecting abnormal network conditions;
  490. .LP
  491.     c)
  492.     investigating and identifying  the reasons for abnormal
  493. network conditions;
  494. .LP
  495.     d)
  496.     initiating corrective action and/or control;
  497. .LP
  498.     e)
  499.     cooperating and coordinating actions with other network
  500. management centres, both domestic and international, on matters
  501. concerned with international network management and service
  502. restoration;
  503. .LP
  504.     f
  505. )
  506.     cooperating and coordinating with other work
  507. areas (e.g., maintenance, operator services or planning) on
  508. matters which affect service;
  509. .LP
  510.     g)
  511.     issuing reports of abnormal network situations, actions
  512. taken and results obtained to higher authority and other
  513. involved departments and Administrations, as required;
  514. .LP
  515.     h)
  516.     providing advance planning for known or predictable network
  517. situations.
  518. .sp 2P
  519. .LP
  520. \fB7\fR     \fBCooperation and coordination\fR 
  521. .sp 1P
  522. .RT
  523. .PP
  524. Effective network management depends on the prompt availability of information 
  525. indicating when and where a problem is occurring, and a trained 
  526. group working in cooperation with all parts of the telecommunications
  527. organization. Just as there is a need for coordination in planning and 
  528. building the network, there also is a need for coordination in managing 
  529. it. The network is such that equipment malfunctions or overloads frequently 
  530. produce 
  531. unacceptable performance at a distance from the physical location of the
  532. problem. Therefore, those who monitor and manage the network, both nationally 
  533. and internationally, must cooperate to ensure satisfactory service. 
  534. .PP
  535. Network management is highly technical in nature, and depends on the skill 
  536. and creativity of those who share an understanding of network management 
  537. philosophy, objectives, terminology, tools and techniques. These items 
  538. are 
  539. specified in Recommendations\ E.410 through\ E.414, and provide a basis 
  540. for the cooperation and coordination which are a vital part of network 
  541. management. 
  542. .bp
  543. .RT
  544. .sp 2P
  545. .LP
  546. \fB8\fR     \fBFurther Recommendations on network management\fR 
  547. .sp 1P
  548. .RT
  549. .PP
  550. 8.1
  551. Recommendation E.411 provides operational guidance for
  552. network management including:
  553. .sp 9p
  554. .RT
  555. .LP
  556.     \(em
  557.     status and performance parameters;
  558. .LP
  559.     \(em
  560.     expansive and protective traffic controls;
  561. .LP
  562.     \(em
  563.     criteria for application of controls.
  564. .PP
  565. 8.2
  566. Recommendation E.412 provides information on network management
  567. controls:
  568. .LP
  569.     \(em
  570.     traffic to be controlled;
  571. .LP
  572.     \(em
  573.     exchange controls;
  574. .LP
  575.     \(em
  576.     automatic controls;
  577. .LP
  578.     \(em
  579.     status of controls;
  580. .LP
  581.     \(em
  582.     operator controls.
  583. .PP
  584. 8.3
  585. Recommendation E.413 provides guidance on planning for
  586. events such as:
  587. .LP
  588.     \(em
  589.     peak calling days;
  590. .LP
  591.     \(em
  592.     failures of transmission systems;
  593. .LP
  594.     \(em
  595.     failures of exchanges;
  596. .LP
  597.     \(em
  598.     failures of common channel signalling systems;
  599. .LP
  600.     \(em
  601.     mass\(hycalling situations;
  602. .LP
  603.     \(em
  604.     disasters;
  605. .LP
  606.     \(em
  607.     introduction of new services.
  608. .PP
  609. 8.4
  610. Recommendation E.414 provides guidance on the functional
  611. elements of a network management organization which need to be
  612. identified internationally as contact points. These comprise:
  613. .LP
  614.     \(em
  615.     planning and liaison;
  616. .LP
  617.     \(em
  618.     implementation and control;
  619. .LP
  620.     \(em
  621.     development.
  622. .PP
  623. 8.5
  624. It is emphasized that it is not necessary to meet the full
  625. scope of these Recommendations to achieve some benefit from the application
  626. of network management, particularly when getting started. However, the
  627. Recommendations do provide detailed information over a wide range of
  628. techniques, some of which can be implemented readily, whilst others may 
  629. require considerable planning and design effort. Additional information 
  630. may also be 
  631. found in the handbook on Quality of service, network management and
  632. maintenance\ [1].
  633. .sp 2P
  634. .LP
  635.     \fBReference\fR 
  636. .sp 1P
  637. .RT
  638. .LP
  639. [1]
  640.      CCITT Manual \fIQuality of service, network management and maintenance\fR 
  641. , ITU, Geneva, 1984. 
  642. .sp 2P
  643. .LP
  644. \fBRecommendation\ E.411\fR 
  645. .RT
  646. .sp 2P
  647. .sp 1P
  648. .ce 1000
  649. \fBINTERNATIONAL\ NETWORK\ MANAGEMENT\ \(em\ OPERATIONAL\ GUIDANCE\fR 
  650. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.411''
  651. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.411    %'
  652. .ce 0
  653. .sp 1P
  654. .LP
  655. \fB1\fR     \fBIntroduction\fR 
  656. .sp 1P
  657. .RT
  658. .PP
  659. Network management requires real\(hytime monitoring of current network 
  660. status and performance and the ability to take prompt action to control 
  661. the 
  662. flow of traffic when necessary (see Recommendation\ E.410). Operational 
  663. guidance to meet these requirements, including a description of status 
  664. and performance parameters, traffic controls and the criteria for their 
  665. application are 
  666. included in this Recommendation. It should be noted that the complete range 
  667. of parameters and traffic controls are not necessary for the introduction 
  668. of a 
  669. limited network management capability, however a comprehensive selection 
  670. will bring substantial benefit (see Recommendation\ E.410, \(sc\ 5). In 
  671. addition, some 
  672. guidance on beginning network management is provided, along with information 
  673. on developing a network management centre and the use of common channel 
  674. signalling for network management purposes. 
  675. .bp
  676. .RT
  677. .sp 2P
  678. .LP
  679. \fB2\fR     \fBInformation requirements\fR 
  680. .sp 1P
  681. .RT
  682. .PP
  683. 2.1
  684. Network management requires information of where and why
  685. difficulties are occurring or are likely to occur in the network. This
  686. information is essential to identify the source and effect of a difficulty 
  687. at the earliest possible time, and will form the basis for any network 
  688. management action which is taken. 
  689. .sp 9p
  690. .RT
  691. .PP
  692. 2.2
  693. The information relating to current difficulties can be obtained   from:
  694. .LP
  695.     a)
  696.     real\(hytime surveillance of the status and performance of the  network;
  697. .LP
  698.     b)
  699.     information from telephone operators as to where they are
  700. experiencing difficulties; or where they are receiving customer
  701. complaints of difficulties;
  702. .LP
  703.     c)
  704.     transmission system failure and planned outage reports
  705. (these reports need not relate only to the network local to one
  706. Administration, but should reflect the whole international
  707. network);
  708. .LP
  709.     d)
  710.     international or national exchange failures and planned
  711. outage reports;
  712. .LP
  713.     e)
  714.     news media reports detailing unforeseen events which
  715. stimulate traffic (for example, natural disasters).
  716. .PP
  717. 2.3
  718. The information relating to difficulties which are likely to
  719. occur in the future will be obtained from:
  720. .LP
  721.     a)
  722.     reports of future planned outages of transmission systems;
  723. .LP
  724.     b)
  725.     reports of future planned outages of international or
  726. national exchanges;
  727. .LP
  728.     c)
  729.     knowledge of special events (for example, international
  730. sporting events, political elections);
  731. .LP
  732.     d)
  733.     knowledge of national holidays and festivals (e.g.,
  734. Christmas Day, New Year's Day);
  735. .LP
  736.     e)
  737.     an analysis of past network performance.
  738. .PP
  739. 2.4
  740. The system availability information point, defined in
  741. Recommendation\ M.721, will provide a ready source for much of the information 
  742. indicated above. 
  743. .sp 2P
  744. .LP
  745. \fB3\fR     \fBNetwork status and performance data\fR 
  746. .sp 1P
  747. .RT
  748. .PP
  749. 3.1
  750. In order to identify where and when difficulties are occurring in the network, 
  751. or are likely to occur, data will be required which will 
  752. indicate the status and measure the performance of the network. Such data 
  753. will require real\(hytime collection and processing, and may require the 
  754. use of 
  755. thresholds (see \(sc\ 5.1).
  756. .sp 9p
  757. .RT
  758. .PP
  759. 3.2
  760. Data may be collected in various ways which include counters in
  761. electromechanical exchanges which can be read manually when required
  762. (e.g.,\ during periods of heavy traffic or special events), data output 
  763. reports from SPC exchanges, or computerized network management operations 
  764. systems which can collect and process data from a large number of exchanges. 
  765. .PP
  766. 3.3
  767. Network status information includes information on the status of exchanges, 
  768. circuit groups and common channel signalling systems. This status 
  769. information can be provided by one or more types of displays. These may 
  770. include printers, video displays, and/or indicators on a display board 
  771. or network 
  772. management console. To be useful, network status indicators should be available 
  773. as rapidly as possible. 
  774. .PP
  775. 3.3.1
  776. Exchange status information includes the following:
  777. .LP
  778.     Load measurements
  779. \(em These are provided by attempt counts, usage or occupancy data, data 
  780. on the percent of real\(hytime capacity available 
  781. (or in use), blocking rates, percentage of equipment in use, counts
  782. of second trials,\ etc.
  783. .LP
  784.     Congestion measurements
  785. \(em These are provided by
  786. measurements
  787. of the delay in serving incoming calls, holding times of equipment,
  788. average call processing and set\(hyup time, queue lengths for common
  789. control equipment (or software queues), and counts of equipment
  790. time\(hyouts,\ etc.
  791. .bp
  792. .LP
  793.     Service availability of exchange equipment
  794. \(em This
  795. information
  796. will show when major items of equipment are made busy to traffic. This
  797. could highlight a cause of difficulty or give advance warning that
  798. difficulties could arise if demand increases.
  799. .LP
  800.     Congestion indicators
  801. \(em In addition to the above,
  802. indicators
  803. can be provided by SPC exchanges which show the degree of congestion.
  804. These indicators can show:
  805. .LP
  806.     \(em
  807.     moderate congestion
  808. Level 1;
  809. .LP
  810.     \(em
  811.     serious congestion
  812. Level 2;
  813. .LP
  814.     \(em
  815.     unable to process calls
  816. Level 3.
  817. .LP
  818.     \fINote\fR \ \(em\ While this is desirable, SPC exchanges may not be able to
  819. provide a level\ 3 indicator during catastrophic failures.
  820. .PP
  821. The availability of specific exchange status information will
  822. depend on the switching technology employed by each Administration. Details 
  823. of exchange measurements are found in Recommendations\ E.502 and\ Q.544. 
  824. .PP
  825. 3.3.2
  826. Circuit group status information
  827. relates to the
  828. following:
  829. .LP
  830.     \(em
  831.     status of all circuit groups available to a destination;
  832. .LP
  833.     \(em
  834.     status of individual circuit sub\(hygroups in a circuit group;
  835. .LP
  836.     \(em
  837.     status of circuits on each circuit group.
  838. .LP
  839.     Status indicators can be provided to show when the available
  840. network is fully utilized by indicating:
  841. .LP
  842.     \(em
  843.     when all circuits in a circuit group are busy;
  844. .LP
  845.     \(em
  846.     when all circuits in a circuit sub\(hygroup are busy;
  847. .LP
  848.     \(em
  849.     when all circuit groups available to a destination are
  850. busy.
  851. .PP
  852. This would indicate that congestion is present or imminent. Status information 
  853. can be provided to show the availability of the network for 
  854. service, by reporting the number or percentage of circuits on each circuit
  855. group that are made busy or are available for traffic.
  856. .PP
  857. This information could identify the cause of difficulty or give
  858. advance warning that difficulties may arise as the demand increases.
  859. .RT
  860. .PP
  861. 3.3.3
  862. Common channel signalling system status provides information
  863. that will indicate failure or signalling congestion within the system. It
  864. includes such items as:
  865. .LP
  866.     \(em
  867.     receipt of a transfer prohibited signal (Signalling Systems   Nos.\ 6 and\ 7),
  868. .LP
  869.     \(em
  870.     initiation of an emergency restart procedure (Signalling
  871. System No.\ 6),
  872. .LP
  873.     \(em
  874.      presence of a signalling terminal buffer overflow condition (Signalling 
  875. System No.\ 6), 
  876. .LP
  877.     \(em
  878.     signal link unavailability (Signalling System No. 7),
  879. .LP
  880.     \(em
  881.     signal route unavailability (Signalling System No. 7),
  882. .LP
  883.     \(em
  884.     destination inaccessible (Signalling
  885. System No. 7).
  886. .PP
  887. This information may identify the cause of difficulty or give
  888. advance warning that difficulties may arise as the demand increases.
  889. .PP
  890. 3.3.3.1
  891. Network management actions may help to reduce congestion in
  892. common channel signalling systems by reducing traffic being offered to 
  893. common channel signalling circuit groups, or by diverting traffic to conventional 
  894. signalling circuit groups.
  895. .PP
  896. 3.4
  897. Network performance data should relate to the following:
  898. .LP
  899.     \(em
  900.     traffic performance on each circuit group;
  901. .LP
  902.     \(em
  903.     traffic performance to each destination;
  904. .LP
  905.     \(em
  906.     effectiveness of network management actions.
  907. .PP
  908. It may also be desirable to assemble performance data in terms of circuit 
  909. group and destination combinations and/or traffic class (for example, operator\(hydialled, 
  910. subscriber\(hydialled, transit). (See Recommendation\ E.412, 
  911. \(sc\ 2.1.)
  912. .PP
  913. 3.5
  914. Data collection should be based on a system of measurement
  915. which is either continuous or of a sufficiently rapid sampling rate to 
  916. give the required information. For example, for common control switching 
  917. equipment, the sampling rate may need to be as frequent as every second. 
  918. .bp
  919. .PP
  920. Reports on network status and performance should be provided
  921. periodically, for example, on a 3\ minute, 5\ minute, 15\ minute, 30\ minute or
  922. hourly basis, with the more frequent reports usually being more useful.
  923. However, the more frequent reports may produce erratic data due to the
  924. peakedness of traffic, especially on small circuit groups. Data reports
  925. compiled by a network management operations system take on added value 
  926. in that a more global view of network performance is provided. 
  927. .PP
  928. 3.6
  929. The network performance data is generally expressed in
  930. parameters which help to identify difficulties in the network.
  931. Among these parameters are:
  932. .sp 1P
  933. .LP
  934. 3.6.1
  935.     \fBpercentage overflow (% OFL)\fR 
  936. .sp 9p
  937. .RT
  938. .PP
  939. % OFL indicates the relationship between the total bids offered to a circuit 
  940. group or destination, in a specified period of time, and the quantity of 
  941. bids not finding a free circuit. It will, therefore, give an indication 
  942. of the overflow from one circuit group to another, or the bids which fail 
  943. because all circuit groups to a destination are busy. 
  944. \v'6p'
  945. .RT
  946. .sp 1P
  947. .ce 1000
  948. % OFL =
  949. @ { verflows~bids (to~another~circuit~group~or~to~circuit~busy~signal) } over { otal~bids~for~the~circuit~group (or~all~circuit~groups~to~a~destination) } @  \(mu 100
  950. .ce 0
  951. .sp 1P
  952. .LP
  953. .sp 1
  954. .LP
  955. International networks contain one\(hyway and both\(hyway operated
  956. circuits, and their traffic flow characteristics are inherently different. 
  957. This difference needs to be taken into account when calculating BCH and 
  958. SCH either by: 
  959. .LP
  960.     i)
  961.     multiplying the number of one\(hyway circuits by 2 to derive an
  962. equivalent number of both\(hyway circuits or;
  963. .LP
  964.     ii)
  965.     dividing the number of both\(hyway circuits by 2 to derive an
  966. equivalent number of one\(hyway circuits.
  967. .LP
  968.     When analyzing BCH and SCH data, and when BCH and SCH data are
  969. exchanged between Administrations, it is essential that the method used is
  970. understood so that erroneous conclusions may be avoid
  971.     ed.
  972. .FE
  973. .sp 1P
  974. .LP
  975. 3.6.2
  976.     \fBbids per circuit per hour (BCH)\fR 
  977. .sp 9p
  978. .RT
  979. .PP
  980. BCH is an indication of the average number of bids per circuit, in a specified 
  981. time interval. It will therefore identify the demand and, when 
  982. measured at each end of a both\(hyway operated circuit group, will identify the
  983. direction of greater demand.
  984. \v'6p'
  985. .RT
  986. .sp 1P
  987. .ce 1000
  988. BCH = 
  989. @ { ids~per~hour } over { uantity~of~circuits~available~for~service } @ 
  990. .ce 0
  991. .sp 1P
  992. .PP
  993. .sp 1
  994. It is not necessary to accumulate data for an hour to calculate
  995. BCH. However, the calculated BCH must be adjusted when data accumulation is
  996. less than hourly. For example, the bids should be doubled if 1/2\ hour 
  997. data is used. The result would be BCH for the data collection period. 
  998. .sp 1P
  999. .LP
  1000. 3.6.3
  1001.     \fBanswer seizure ratio (ASR)\fR 
  1002. .sp 9p
  1003. .RT
  1004. .PP
  1005. ASR gives the relationship between the number of seizures that
  1006. result in an answer signal and the total number of seizures. This is a 
  1007. direct measure of the effectiveness of the service being offered onward 
  1008. from the point of measurement and is usually expressed as a percentage 
  1009. as follows: 
  1010. \v'6p'
  1011. .RT
  1012. .sp 1P
  1013. .ce 1000
  1014. ASR = 
  1015. @ { eizures~resulting~in~answer~signal } over { otal~seizures } @  \(mu 100
  1016. .ce 0
  1017. .sp 1P
  1018. .PP
  1019. .sp 1
  1020. Measurement of ASR may be made on a circuit group or on a
  1021. destination basis.
  1022. .bp
  1023. .sp 1P
  1024. .LP
  1025. 3.6.4
  1026.     \fBanswer bid ratio (ABR)\fR 
  1027. .sp 9p
  1028. .RT
  1029. .PP
  1030. ABR gives the relationship between the number of bids that result in an 
  1031. answer signal and the total number of bids. ABR may be made on a circuit 
  1032. group or on a destination basis. 
  1033. \v'6p'
  1034. .RT
  1035. .sp 1P
  1036. .ce 1000
  1037. ABR = 
  1038. @ { ids~resulting~in~answer~signal } over { otal~bids } @  \(mu 100
  1039. .ce 0
  1040. .sp 1P
  1041. .PP
  1042. .sp 1
  1043. ABR is expressed as a percentage and is a direct measure of the
  1044. effectiveness of traffic onward from the point of measurement. It is similar 
  1045. to ASR except that it includes bids that do not result in a seizure. 
  1046. .sp 1P
  1047. .LP
  1048. 3.6.5
  1049.     \fBseizures per circuit per hour (SCH)\fR 
  1050. .sp 9p
  1051. .RT
  1052. .PP
  1053. SCH is an indication of the average number of times, in a
  1054. specified
  1055. time interval, that each circuit group is seized. When related to the expected 
  1056. values of average call holding times and effective call/seizure rate for 
  1057. the 
  1058. circuit group, it will give an indication of the effectiveness of the service 
  1059. being offered. 
  1060. \v'6p'
  1061. .RT
  1062. .sp 1P
  1063. .ce 1000
  1064. SCH = 
  1065. @ { eizures~per~hour } over { uantity~of~circuits~available~for~service } @ 
  1066. .ce 0
  1067. .sp 1P
  1068. .PP
  1069. .sp 1
  1070. It is not necessary to accumulate data for an hour to compute SCH. (See 
  1071. \(sc\ 3.6.2 \(em BCH.) 
  1072. .sp 1P
  1073. .LP
  1074. 3.6.6
  1075.     \fBoccupancy\fR 
  1076. .sp 9p
  1077. .RT
  1078. .PP
  1079. Occupancy can be represented in units (for example, erlangs,
  1080. hundred\(hycall\(hyseconds (CCS) or as a percentage. It can be measured 
  1081. as a total 
  1082. for a destination or for a circuit group and as an average per circuit on a
  1083. circuit group. Its use for network management purposes is to show usage 
  1084. and to identify unusual traffic levels. 
  1085. .RT
  1086. .sp 1P
  1087. .LP
  1088. 3.6.7
  1089.     \fBmean holding time per seizure\fR 
  1090. .sp 9p
  1091. .RT
  1092. .PP
  1093. This is the total holding time divided by the total number of
  1094. seizures and can be calculated on a circuit group basis or for switching
  1095. equipment.
  1096. .RT
  1097. .sp 1P
  1098. .LP
  1099. 3.6.8
  1100.     \fBbusy\(hyflash seizure ratio (BFSR)\fR 
  1101. .sp 9p
  1102. .RT
  1103. .PP
  1104. BFSR gives the relationship between the number of seizures that
  1105. result in a \*Qbusy\(hyflash\*U signal (or its equivalent) and the total 
  1106. number of 
  1107. seizures. Measurement of BFSR is usually made on a circuit group
  1108. basis.
  1109. \v'6p'
  1110. .RT
  1111. .sp 1P
  1112. .ce 1000
  1113. BFSR = 
  1114. @ { eizures~resulting~in~a~\*Qbusy\(hyflash\*U } over { otal~seizures } @  \(mu 100
  1115. .ce 0
  1116. .sp 1P
  1117. .PP
  1118. .sp 1
  1119. \fINote\fR \ \(em\ The source of \*Qbusy\(hyflash\*U signals, or their 
  1120. equivalent, will vary with the signalling system used. Therefore, the calculated 
  1121. BFSR on 
  1122. individual circuit groups may naturally be different, and as a result, 
  1123. caution should be used when comparing BFSR among circuit groups. 
  1124. .bp
  1125. .PP
  1126. 3.7
  1127. The number of parameters possible or necessary for particular
  1128. Administration purposes will depend upon a variety of factors. These will
  1129. include:
  1130. .LP
  1131.     a)
  1132.     the data available at an exchange;
  1133. .LP
  1134.     b)
  1135.      the particular routing arrangements employed (for example, SCH and BCH 
  1136. relate to circuit group performance only; ABR, ASR, 
  1137. and %\ OFL can relate to circuit group or destination performance);
  1138. .LP
  1139.     c)
  1140.     the interrelationships which exist between the parameters
  1141. (for example, SCH can give similar indications to ASR \(em\ see \(sc\ 3.6.5
  1142. above).
  1143. .sp 2P
  1144. .LP
  1145. \fB4\fR     \fBInterpretation of parameters\fR 
  1146. .sp 1P
  1147. .RT
  1148. .PP
  1149. The interpretation of parameters on which network management
  1150. actions are based can most conveniently be made by considering the originating 
  1151. international exchange as the reference point (see Figure\ 1/E.411). 
  1152. .RT
  1153. .LP
  1154. .rs
  1155. .sp 11P
  1156. .ad r
  1157. \fBFigure 1/E.411, p.\fR 
  1158. .sp 1P
  1159. .RT
  1160. .ad b
  1161. .RT
  1162. .PP
  1163. From this reference point, the factors which affect call
  1164. completion can broadly be divided into three main components:
  1165. .LP
  1166.     a)
  1167.     switching loss (near\(hyend loss);
  1168. .LP
  1169.     b)
  1170.     circuit congestion loss (near\(hyend loss);
  1171. .LP
  1172.     c)
  1173.     distant network loss (far\(hyend loss).
  1174. .sp 1P
  1175. .LP
  1176. 4.1
  1177.     \fISwitching loss\fR 
  1178. .sp 9p
  1179. .RT
  1180. .PP
  1181. Switching loss may be due to:
  1182. .RT
  1183. .LP
  1184.     1)
  1185.     common equipment or switchblock congestion, or queue
  1186. overflows or processor overloads;
  1187. .LP
  1188.     2)
  1189.     failures in incoming signalling;
  1190. .LP
  1191.     3)
  1192.      subscriber/operator dependent errors, such as insufficient or invalid 
  1193. digits, premature call abandonment,\ etc.; 
  1194. .LP
  1195.     4)
  1196.     routing errors, such as barred transit access;
  1197. .LP
  1198.     5)
  1199.     other technical failures.
  1200. .PP
  1201. Guidance to the identification of switching loss can be obtained from \(sc\ 
  1202. 3.3. 
  1203. .sp 1P
  1204. .LP
  1205. 4.2
  1206.     \fICircuit congestion loss\fR 
  1207. .sp 9p
  1208. .RT
  1209. .PP
  1210. This loss will depend on:
  1211. .RT
  1212. .LP
  1213.     1)
  1214.     the number of circuits available for a destination, and:
  1215. .LP
  1216.     2)
  1217.     the level of demand for that destination,
  1218. .LP
  1219.     3)
  1220.     the traffic performance on the circuit groups to that
  1221. destination.
  1222. .bp
  1223. .PP
  1224. Indication that circuit congestion loss may occur can be obtained from 
  1225. the status information detailed in \(sc\ 3.3.2 above. 
  1226. .PP
  1227. Circuit congestion loss can be identified by any of the
  1228. following:
  1229. .RT
  1230. .LP
  1231.     \(em
  1232.     percentage overflow (see \(sc\ 3.6.1),
  1233. .LP
  1234.     \(em
  1235.     a difference between the \*Qbids per circuit per hour\*U and
  1236. \*Qseizures per circuit per hour\*U measurements on the final circuit
  1237. group (see \(sc\(sc\ 3.6.2 and\ 3.6.5),
  1238. .LP
  1239.     \(em
  1240.      a difference between the \*Qanswer bid ratio\*U and the \*Qanswer seizure 
  1241. ratio\*U (see \(sc\(sc\ 3.6.3 and\ 3.6.4). 
  1242. .PP
  1243. It should be noted that for both\(hyway operated circuit groups,
  1244. excessive demand in the incoming direction may also cause circuit congestion
  1245. loss. This can be identified by comparing incoming and outgoing bids, seizures 
  1246. or occupancy. 
  1247. .sp 1P
  1248. .LP
  1249. 4.3
  1250.     \fIDistant network loss\fR 
  1251. .sp 9p
  1252. .RT
  1253. .PP
  1254. Distant network loss may be divided into:
  1255. .RT
  1256. .LP
  1257.     1)
  1258.     \fItechnical loss\fR  |  due to distant exchange and national
  1259. circuit faults,
  1260. .LP
  1261.     2)
  1262.      \fIsubscriber dependent loss\fR  |  due to subscriber B busy, no answer, 
  1263. invalid distant number, number unavailable,\ etc., 
  1264. .LP
  1265.     3)
  1266.      \fItraffic dependent loss\fR  |  these losses are due to lack of distant 
  1267. network capacity to meet traffic demand. 
  1268. .PP
  1269. Under normal conditions, and for a large sample measured over a
  1270. long period, distant network loss can be said to have a fixed or ambient
  1271. overhead loss (this value depends on destination with some hour\(hyby\(hyhour 
  1272. and 
  1273. day\(hyby\(hyday variations).
  1274. .PP
  1275. Under abnormal situations (heavy demand, failures, etc.) distant
  1276. network losses can be significantly affected. Variations in distant network
  1277. loss can be identified by any of the following:
  1278. .RT
  1279. .LP
  1280.     \(em
  1281.     answer seizure ratio (see \(sc\ 3.6.3) (this is a direct
  1282. measurement),
  1283. .LP
  1284.     \(em
  1285.     seizures per circuit per hour (see \(sc\ 3.6.5) (this is an
  1286. indirect measurement),
  1287. .LP
  1288.     \(em
  1289.     mean holding time per seizure (see \(sc\ 3.6.7) (this is an
  1290. indirect measurement),
  1291. .LP
  1292.     \(em
  1293.     busy\(hyflash seizure ratio (see \(sc\ 3.6.8) (this is a direct
  1294. measurement).
  1295. .sp 2P
  1296. .LP
  1297. \fB5\fR     \fBCriteria for action\fR 
  1298. .sp 1P
  1299. .RT
  1300. .PP
  1301. 5.1
  1302. The basis for the decision on whether any network management
  1303. action should be taken will depend upon real\(hytime information on the 
  1304. status and performance of the network. It is advantageous if the output 
  1305. of this 
  1306. information can be initially restricted to that which is required to identify 
  1307. possible difficulties in the network. This can be achieved by setting threshold 
  1308. values for performance parameters, and for the number or the percentage 
  1309. of 
  1310. circuits and common control equipment which are in service, such that when
  1311. these threshold values are crossed, network management action can be
  1312. considered. These threshold values will represent some of the criteria 
  1313. by which decisions are reached. 
  1314. .sp 9p
  1315. .RT
  1316. .PP
  1317. 5.2
  1318. Indications that a threshold has been crossed and \*Qall circuits on a 
  1319. circuit group are busy\*U and \*Qall circuit groups to a destination are 
  1320. busy\*U 
  1321. may be used to direct attention to the particular area of the network for 
  1322. which detailed performance information will then be required. 
  1323. .PP
  1324. 5.3
  1325. The decision on whether or not to take network management action, and what 
  1326. action will be taken, is the responsibility of the network management personnel. 
  1327. In addition to the criteria mentioned above, this decision will be based 
  1328. on a number of factors, which could include: 
  1329. .LP
  1330.     \(em
  1331.     a knowledge of the source of the difficulty;
  1332. .LP
  1333.     \(em
  1334.     detailed performance and status information;
  1335. .LP
  1336.     \(em
  1337.     any predetermined plans that exist
  1338. (see Recommendation\ E.413);
  1339. .LP
  1340.     \(em
  1341.     experience with and knowledge of the network;
  1342. .LP
  1343.     \(em
  1344.     routing plan employed;
  1345. .LP
  1346.     \(em
  1347.     local traffic patterns;
  1348. .LP
  1349.     \(em
  1350.     ability to control the flow of traffic
  1351. (see Recommendation\ E.412).
  1352. .PP
  1353. This personnel is responsible for ensuring that conventional
  1354. network management controls, once activated, are not left
  1355. unsupervised.
  1356. .bp
  1357. .sp 2P
  1358. .LP
  1359. \fB6\fR     \fBNetwork management actions\fR 
  1360. .sp 1P
  1361. .RT
  1362. .sp 1P
  1363. .LP
  1364. 6.1
  1365.     \fIGeneral\fR 
  1366. .sp 9p
  1367. .RT
  1368. .PP
  1369. Network management actions fall into two broad
  1370. categories:
  1371. .RT
  1372. .LP
  1373.     a)
  1374.     \*Qexpansive\*U actions, which are designed to make available
  1375. lightly loaded parts of the network to traffic experiencing
  1376. congestion;
  1377. .LP
  1378.     b)
  1379.      \*Qprotective\*U actions, which are designed to remove traffic from the 
  1380. network during congestion which has a low probability 
  1381. of resulting in successful calls.
  1382. .PP
  1383. Normally, the first choice response to a network problem would be an expansive 
  1384. action. Protective actions would be used if expansive actions 
  1385. were not available or not effective.
  1386. .PP
  1387. Network management actions may be taken:
  1388. .RT
  1389. .LP
  1390.     \(em
  1391.      according to plans which have been mutually agreed to between Administrations 
  1392. prior to the event (see Recommendation\ E.413); 
  1393. .LP
  1394.     \(em
  1395.      according to ad hoc arrangements agreed to at the time of an event (see 
  1396. Recommendation\ E.413); 
  1397. .LP
  1398.     \(em
  1399.     by an individual Administration wishing to reduce its
  1400. traffic entering the international network, or to protect its
  1401. own network.
  1402. .sp 1P
  1403. .LP
  1404. 6.2
  1405.     \fIExpansive actions\fR 
  1406. .sp 9p
  1407. .RT
  1408. .PP
  1409. Expansive actions involve the rerouting of traffic from circuit
  1410. groups experiencing congestion to other parts of the network which are 
  1411. lightly loaded with traffic, for example, due to differences in busy hours. 
  1412. .PP
  1413. Examples of expansive actions are:
  1414. .RT
  1415. .LP
  1416.     a)
  1417.      establishing temporary alternative routing arrangements in addition to 
  1418. those normally available; 
  1419. .LP
  1420.     b)
  1421.     in a country where there is more than one international
  1422. exchange, temporarily reorganizing the distribution of outgoing
  1423. (or incoming) international traffic;
  1424. .LP
  1425.     c)
  1426.      establishing alternative routings into the national network for incoming 
  1427. international traffic; 
  1428. .LP
  1429.     d)
  1430.     establishing alternative routings to an international
  1431. exchange in the national network for originating international
  1432. traffic.
  1433. .PP
  1434. The protective action of inhibiting one direction of operation of both\(hyway 
  1435. circuits [see \(sc\ 6.3 a)] can have an expansive effect in the other 
  1436. direction of operation.
  1437. .sp 1P
  1438. .LP
  1439. 6.3
  1440.     \fIProtective actions\fR 
  1441. .sp 9p
  1442. .RT
  1443. .PP
  1444. Protective actions involve removing traffic from the network during congestion 
  1445. which has a low probability of resulting in successful calls. Such traffic 
  1446. should be removed as close as possible to its origin, thus making more 
  1447. of the network available to traffic which has a higher probability of success. 
  1448. .PP
  1449. Examples of protective actions are:
  1450. .RT
  1451. .LP
  1452.     a)
  1453.     Temporary removal of circuits from service (circuit
  1454. busying). This action may be taken when a distant part of the
  1455. network is experiencing serious congestion.
  1456. .LP
  1457.     \fINote\fR \ \(em\ In the case of both\(hyway circuits, it may only be
  1458. necessary to inhibit one direction of operation. This is called
  1459. directionalization
  1460. .
  1461. .LP
  1462.     b)
  1463.     Special instructions to operators. For example, such
  1464. instructions may require that only a limited number of attempts
  1465. (or none at all) be made to set up a call via a congested circuit
  1466. group or exchange, or to a particular destination experiencing
  1467. congestion.
  1468. .LP
  1469.     c)
  1470.     Special recorded announcements. Such announcements may be
  1471. connected at an international or national exchange and, when there
  1472. is serious congestion within part of the network, would advise
  1473. customers (and/or operators) to take appropriate action.
  1474. .LP
  1475.     d)
  1476.     Inhibiting overflow traffic. This action prevents traffic
  1477. from overflowing onto circuit groups or into distant exchanges
  1478. which are already experiencing congestion.
  1479. .bp
  1480. .LP
  1481.     e)
  1482.      Inhibiting direct traffic. This action reduces the traffic accessing 
  1483. a circuit group in order to reduce the loading on the 
  1484. distant network.
  1485. .LP
  1486.     f
  1487. )
  1488.      Inhibiting traffic to a particular destination (code blocking or call 
  1489. gapping). This action may be taken when it is 
  1490. known that a distant part of the network is experiencing congestion.
  1491. .LP
  1492.     g)
  1493.      Circuit reservation. This action reserves the last few idle circuits 
  1494. in a circuit group for a particular type of traffic. 
  1495. .PP
  1496. 6.4
  1497. Information on the network management controls (and their
  1498. method of activation) which can be used for expansive and protective actions 
  1499. is found in Recommendation\ E.412. 
  1500. .sp 2P
  1501. .LP
  1502. 6.5
  1503.     \fIActions during disasters\fR 
  1504. .sp 1P
  1505. .RT
  1506. .PP
  1507. 6.5.1
  1508. Disasters whether man\(hymade or natural can result in damage to the telephone 
  1509. network, they can give rise to heavy calling, or both. 
  1510. .sp 9p
  1511. .RT
  1512. .PP
  1513. 6.5.2
  1514. A single point of contact for network\(hyrelated information should be 
  1515. established to prevent confusion, duplication of effort, and to ensure 
  1516. an 
  1517. orderly process of returning communications to normal. It is recommended 
  1518. that the single point of contact be the network management implementation 
  1519. and 
  1520. control point (see Recommendation\ E.414, \(sc\ 4) within the Administration
  1521. affected by the disaster.
  1522. .PP
  1523. 6.5.3
  1524. The role of the network management implementation and control
  1525. point may vary depending on the size or impact of a disaster. However, the
  1526. following are functions which may be required:
  1527. .LP
  1528.     \(em
  1529.     assess the impact of the disaster on the network
  1530. (transmission systems, exchanges, circuit groups, destination codes,
  1531. isolated destinations);
  1532. .LP
  1533.     \(em
  1534.     provide status information, as appropriate, to:
  1535. .LP
  1536.     i)
  1537.     operator services
  1538. .LP
  1539.     ii)
  1540.     public relations and media
  1541. .LP
  1542.     iii)
  1543.     government agencies
  1544. .LP
  1545.     iv)
  1546.     other network management implementation and
  1547. control points;
  1548. .LP
  1549.     \(em
  1550.     develop and implement control strategies (expansive and
  1551. protective);
  1552. .LP
  1553.     \(em
  1554.      assist in determining the need for, and locating, technical equipment 
  1555. to restore communications. 
  1556. .sp 2P
  1557. .LP
  1558. \fB7\fR     \fBExchange of information\fR 
  1559. .sp 1P
  1560. .RT
  1561. .PP
  1562. 7.1
  1563. Effective network management requires good communications and cooperation 
  1564. between the various network management elements within an 
  1565. Administration and with similar elements in other Administrations (see
  1566. Recommendation\ E.414). This includes the exchange of real\(hytime information 
  1567. as to the status and performance of circuit groups, exchanges and traffic 
  1568. flow in distant locations. 
  1569. .sp 9p
  1570. .RT
  1571. .PP
  1572. 7.2
  1573. Such information can be exchanged in a variety of ways, depending on the 
  1574. requirements of the Administrations. Voice communications can be 
  1575. established between or among network management centres using dedicated 
  1576. service circuits or the public telephone network. Certain operational signals, 
  1577. such as switching congestion indicators, may be transported directly by 
  1578. the common 
  1579. channel signalling system. (See Recommendation\ Q.297 for Signalling
  1580. System\ No.\ 6 and
  1581. Recommendations\ Q.722, Q.723, Q.724, Q.762, Q.763 and\ Q.764 for
  1582. Signalling System\ No.\ 7.) Larger data exchange requirements on a
  1583. .LP
  1584. regular basis may be supported by the Telecommunications Management Network
  1585. (TMN) (see Recommendation\ M.30) or by use of a packet switched network
  1586. capability. The transfer of smaller amounts of data on an infrequent basis 
  1587. may be supported by telex or similar media, or by facsimile. 
  1588. .sp 2P
  1589. .LP
  1590. 7.3
  1591.     \fIGuidance on the\fR 
  1592. \fIuse of common channel signalling for network\fR \fImanagement\fR 
  1593. .sp 1P
  1594. .RT
  1595. .PP
  1596. 7.3.1
  1597. Common channel signalling systems provide a fast and reliable means of 
  1598. transfering network management operational signals between exchanges. An 
  1599. example is the transfer of exchange congestion status signals for the
  1600. Automatic
  1601. Congestion Control (ACC) system (see Recommendation\ E.412, \(sc\ 3.1). These
  1602. signals should be given a high priority in common channel signalling flow
  1603. control. Specific details on the application of network management operational 
  1604. signals in Signalling System\ No.\ 6 are found in Recommendation\ Q.297. 
  1605. In the 
  1606. case of Signalling System\ No.\ 7, the details for the Telephone User Part
  1607. (TUP)
  1608. are found in Recommendations\ Q.722, Q.723 and\ Q.724, and the ISDN User Part
  1609. (ISUP) are found in Recommendations\ Q.762, Q.763 and\ Q.764.
  1610. .bp
  1611. .sp 9p
  1612. .RT
  1613. .PP
  1614. 7.3.2
  1615. Signalling System No. 7 may also be used to transfer network
  1616. management
  1617. data and status information between an exchange and its network management
  1618. operations system, and between network management operations systems. It 
  1619. should be noted that in these applications, the volume of data to be transferred 
  1620. can be quite large and its frequency of transmission can be as high as 
  1621. every three minutes. When this data is transferred over signalling links 
  1622. which also handle user signalling traffic, stringent safeguards must be 
  1623. adopted to minimize the risk of signalling system overloads during busy 
  1624. periods when both user 
  1625. signalling traffic and network management data transmissions are at their
  1626. highest levels. These safeguards include the following:
  1627. .LP
  1628.     \(em
  1629.      limiting the amount of network management information to be transferred 
  1630. on signalling links which also carry user signalling 
  1631. messages;
  1632. .LP
  1633.     \(em
  1634.     using dedicated signalling links for network management
  1635. purposes;
  1636. .LP
  1637.     \(em
  1638.     using the telecommunications management network (TMN), or
  1639. the Operations and Maintenance Application Part (OMAP) in Signalling
  1640. System\ No.\ 7 (for further study);
  1641. .LP
  1642.     \(em
  1643.     developing appropriate flow control priorities for
  1644. network management information (for further study);
  1645. .LP
  1646.     \(em
  1647.      equipping the network management operations system in such a way that 
  1648. it can respond to signalling system flow control messages. 
  1649. .sp 2P
  1650. .LP
  1651. \fB8\fR     \fBBeginning network management\fR 
  1652. .sp 1P
  1653. .RT
  1654. .PP
  1655. The introduction of network management into an existing network
  1656. should be viewed as a long\(hyterm project. This long period is
  1657. required:
  1658. .RT
  1659. .LP
  1660.     \(em
  1661.     to gain knowledge and experience of network management;
  1662. .LP
  1663.     \(em
  1664.     to carry out studies on the requirements of an individual
  1665. network;
  1666. .LP
  1667.     \(em
  1668.      to write specifications for network management requirements in present 
  1669. and future telephone exchanges and to hold discussions 
  1670. with manufacturers;
  1671. .LP
  1672.     \(em
  1673.      to oversee the introduction of facilities and to organize and train suitable 
  1674. network management staff; 
  1675. .LP
  1676.     \(em
  1677.     to introduce limited facilities in existing older technology  exchanges.
  1678. .PP
  1679. A rational approach would consist in first using existing limited facilities 
  1680. to manage the network, while at the same time developing full 
  1681. network management facilities with the introduction of modern stored program
  1682. control (SPC) exchanges.
  1683. .sp 2P
  1684. .LP
  1685. 8.1
  1686.     \fIUtilizing existing resources and capabilities\fR 
  1687. .sp 1P
  1688. .RT
  1689. .sp 1P
  1690. .LP
  1691. 8.1.1
  1692.     \fIResponsibility\fR 
  1693. .sp 9p
  1694. .RT
  1695. .PP
  1696. As an important first step, the responsibility for network
  1697. management should be identified and assigned within an organization. This
  1698. initial organization can then be expanded, as required, in accordance with
  1699. Recommendation\ E.414.
  1700. .RT
  1701. .sp 1P
  1702. .LP
  1703. 8.1.2
  1704.     \fITelephone operators\fR 
  1705. .sp 9p
  1706. .RT
  1707. .PP
  1708. Operators are usually aware of problems as they occur in the
  1709. network, and this information can reveal the need to control traffic. The
  1710. operators can then be directed to modify their procedures to reduce repeated
  1711. attempts, or to use alternative routings to a destination. They can also
  1712. provide special information and/or instructions to customers and distant
  1713. operators during unusual situations.
  1714. .RT
  1715. .sp 1P
  1716. .LP
  1717. 8.1.3
  1718.     \fIExchange capabilities\fR 
  1719. .sp 9p
  1720. .RT
  1721. .PP
  1722. Exchanges may have been provided with certain features which can be adapted 
  1723. for network management purposes. Data already available for maintenance 
  1724. or traffic engineering purposes could be used for network management, or 
  1725. could be made available through the addition of an interface unit. In addition, 
  1726. manually operated switches or keys can be provided in electro\(hymechanical
  1727. exchanges to block certain destination codes or to change alternate routing.
  1728. They can be provided separately for each item of common control equipment,
  1729. thereby allowing flexible control of traffic to a destination.
  1730. .bp
  1731. .PP
  1732. The scope for network management in a telecommunications network may depend 
  1733. on the technology of the exchanges in that network. However, close 
  1734. examination of the manufacturers' specifications for SPC exchanges may 
  1735. reveal that certain network management functions may be available, for 
  1736. example, via a maintenance terminal. 
  1737. .RT
  1738. .sp 1P
  1739. .LP
  1740. 8.1.4
  1741.     \fICircuits\fR 
  1742. .sp 9p
  1743. .RT
  1744. .PP
  1745. Both\(hyway circuits can be made busy to one direction of operation to 
  1746. improve the flow of traffic in the other direction. In addition, both\(hyway 
  1747. and one\(hyway circuits can be removed from service, when necessary. Both 
  1748. of these 
  1749. actions may be taken by verbal direction to the responsible maintenance
  1750. organization.
  1751. .RT
  1752. .sp 1P
  1753. .LP
  1754. 8.2
  1755.     \fIImproving capabilities\fR 
  1756. .sp 9p
  1757. .RT
  1758. .PP
  1759. From the experience gained through the use of these simple tools,   more
  1760. sophisticated network management facilities can be specified. In the interest 
  1761. of cost reduction, these up\(hygraded network management capabilities should 
  1762. be 
  1763. planned for introduction as a part of a planned addition or modification 
  1764. to an exchange, and should be specified as a part of the initial installation 
  1765. of new systems. Before purchasing a new exchange, attention should be paid 
  1766. to the 
  1767. ability of the exchange to provide network management requirements as specified 
  1768. in Recommendations\ Q.542 and\ Q.544. 
  1769. .PP
  1770. In some cases, certain off\(hyline network management information storing 
  1771. and processing needs may be accommodated by the use of personal computers. 
  1772. .RT
  1773. .sp 2P
  1774. .LP
  1775. \fB9\fR     \fBConsiderations for the development of network management\fR 
  1776. .sp 1P
  1777. .RT
  1778. .PP
  1779. 9.1
  1780. Network management can be provided on a distributed basis,
  1781. where network management functions are provided \*Qon\(hysite\*U at the 
  1782. exchange, or on a centralized basis, where network management functions 
  1783. for a number of 
  1784. exchanges are provided at a single location. Each approach provides certain
  1785. advantages which should be recognized when deciding which one would be
  1786. appropriate for an Administration's situation. In general, the decentralized
  1787. distributed
  1788. .sp 9p
  1789. .RT
  1790. .LP
  1791. approach may be more appropriate where activity levels are relatively low. 
  1792. It may also be an appropriate way to get started in network management. 
  1793. The 
  1794. centralized approach may be more appropriate in networks where activity 
  1795. levels are high. In some networks, a combination of these approaches may 
  1796. be most 
  1797. effective.
  1798. .sp 1P
  1799. .LP
  1800. 9.2
  1801.     \fIAdvantages of the decentralized (distributed) approach\fR 
  1802. .sp 9p
  1803. .RT
  1804. .PP
  1805. The decentralized (distributed) approach provides certain
  1806. advantages, which include the following:
  1807. .RT
  1808. .LP
  1809.     \(em
  1810.      locally available features and capabilities can be developed and used 
  1811. (see \(sc\ 8.1.3); 
  1812. .LP
  1813.     \(em
  1814.     a more detailed analysis and assessment of localized problems are possible;
  1815. .LP
  1816.     \(em
  1817.     survivability of network management functions is improved,
  1818. since a problem or outage at one location will not usually result
  1819. in the loss of all network management capabilities;
  1820. .LP
  1821.     \(em
  1822.     network management functions may be assigned to existing
  1823. staff, eliminating the need to develop a dedicated, specialized
  1824. staff;
  1825. .LP
  1826.     \(em
  1827.      it may provide an interim capability while a long\(hyterm plan is being 
  1828. developed and deployed. 
  1829. .sp 1P
  1830. .LP
  1831. 9.3
  1832.     \fIAdvantages of the centralized approach\fR 
  1833. .sp 9p
  1834. .RT
  1835. .PP
  1836. A centralized network management centre provides a number of
  1837. operational benefits when compared with a distributed approach, where network 
  1838. management functions are provided \*Qon\(hysite\*U at the exchange. These 
  1839. include:
  1840. .RT
  1841. .LP
  1842.     \(em
  1843.      more effective network management operations. A centralized approach 
  1844. is inherently more effective in dealing with complex, 
  1845. interrelated network problems in the SPC\(hycommon channel
  1846. signalling environment, and will become more so during the
  1847. transition to ISDN. In many cases, the most effective response
  1848. to a problem in the international network might be to take
  1849. action in the national network, and vice\(hyversa. A centralized
  1850. approach simplifies the problem of coordination of activities
  1851. in these cases;
  1852. .bp
  1853. .LP
  1854.     \(em
  1855.      a more \*Qglobal\*U view of network performance. This, in turn, will 
  1856. permit faster and more accurate problem identification, and 
  1857. the development of more effective control strategies which can be
  1858. implemented with less delay;
  1859. .LP
  1860.     \(em
  1861.     a central point of contact for network management, both
  1862. internally and with other Administrations (see
  1863. Recommendation\ E.414);
  1864. .LP
  1865.     \(em
  1866.     more efficient network management operations. The cost of
  1867. staffing and training is reduced, and staff expertise is
  1868. enhanced through specialization.
  1869. .sp 1P
  1870. .LP
  1871. 9.4
  1872.     \fINetwork management operations systems\fR 
  1873. .sp 9p
  1874. .RT
  1875. .PP
  1876. A computer\(hybased network management operations system can provide considerable 
  1877. benefits to a network management centre due to its ability to 
  1878. process large volumes of information and to present that information in a
  1879. common format. The functions of a network management operations system 
  1880. include the following: 
  1881. .RT
  1882. .LP
  1883.     \(em
  1884.      collecting alarms, status information and network management traffic 
  1885. data from exchanges (see \(sc\ 3 and Recommendation\ E.502); 
  1886. .LP
  1887.     \(em
  1888.     processing the collected data and calculating network
  1889. management parameters (see \(sc\ 3 and Recommendation\ E.502);
  1890. .LP
  1891.     \(em
  1892.     providing performance reports (see \(sc\ 9.4.1);
  1893. .LP
  1894.     \(em
  1895.     comparing network management parameters with thresholds to
  1896. identify unusual conditions;
  1897. .LP
  1898.     \(em
  1899.     applying controls in exchanges based on input commands;
  1900. .LP
  1901.     \(em
  1902.     calculating hard\(hyto\(hyreach status of destinations and
  1903. providing this information to exchanges;
  1904. .LP
  1905.     \(em
  1906.      interfacing with network management centre visual displays, and work 
  1907. station terminals and printers; 
  1908. .LP
  1909.     \(em
  1910.     preparing administrative reports;
  1911. .LP
  1912.     \(em
  1913.     maintaining a database of network statistics and
  1914. information.
  1915. .PP
  1916. \fINote\fR \ \(em\ Many of these functions can also be provided to the
  1917. Network Management Centre by each SPC exchange, however, the
  1918. provision of these functions in a network management operations
  1919. system may reduce the requirements placed on the exchanges.
  1920. .sp 1P
  1921. .LP
  1922. 9.4.1
  1923.     \fIPerformance reports\fR 
  1924. .sp 9p
  1925. .RT
  1926. .PP
  1927. Performance reports can be provided in the following
  1928. ways:
  1929. .RT
  1930. .LP
  1931.     i)
  1932.     \fIautomatic data\fR \(em this data is provided automatically as
  1933. specified in the operations system software, and cannot be readily
  1934. changed by the network manager;
  1935. .LP
  1936.     ii)
  1937.     \fIscheduled data\fR \(em this data is provided according to a
  1938. schedule established by the network manager;
  1939. .LP
  1940.     iii)
  1941.      \fIdemand data\fR \(em this data is provided only in response to a specific 
  1942. request by the network manager. In addition to 
  1943. performance data, demand data includes reference data, such as
  1944. the number of circuits provided or available for service, routing
  1945. information, assigned threshold values, numbers of installed
  1946. switching system components,\ etc.;
  1947. .LP
  1948.     iv)
  1949.      \fIexception data\fR \(em this data is provided when a data count or 
  1950. calculation crosses a threshold established by the network manager. 
  1951. .PP
  1952. Data reports can be provided on a regular basis, for example,
  1953. every 3\ minutes, 5\ minutes, 15\ minutes, 30\ minutes, or hour. The specific
  1954. interval for any data report will be determined by the network manager.
  1955. Historic data relating to at least the previous two or three periods should
  1956. also be available.
  1957. .sp 1P
  1958. .LP
  1959. 9.4.2
  1960.     \fIOther considerations\fR 
  1961. .sp 9p
  1962. .RT
  1963. .PP
  1964. It should be noted that shorter collection intervals increase the usefulness 
  1965. of the data to the network manager, but also increase the size and cost 
  1966. of the operations system and may increase the volatility of the data. 
  1967. .bp
  1968. .PP
  1969. It should also be noted that it is important that network management controls 
  1970. should not become completely unavailable due to the failure or 
  1971. malfunction of the network management operations system or of its
  1972. communications links with exchanges. Therefore, network management operations 
  1973. systems should be planned with a high degree of reliability, survivability 
  1974. and security. This could be achieved through the provision of certain essential 
  1975. capabilities (such as controls and automatic routing protection mechanisms)
  1976. on\(hysite in the exchange, or by redundancy in computers and data links, or
  1977. through the provision of alternative stand\(hyby centres.
  1978. .PP
  1979. The failure of a network management operations system should not have an 
  1980. adverse impact on normal traffic flow in the network. 
  1981. .RT
  1982. .ce 1000
  1983. ANNEX\ A
  1984. .ce 0
  1985. .ce 1000
  1986. (to Recommendation E.411)
  1987. .sp 9p
  1988. .RT
  1989. .ce 0
  1990. .ce 1000
  1991. \fBTerminology for network management\fR 
  1992. .sp 1P
  1993. .RT
  1994. .ce 0
  1995. .LP
  1996. A.1
  1997.     \fBcircuit\fR 
  1998. .sp 1P
  1999. .RT
  2000. .PP
  2001. A circuit connects two exchanges. A national circuit connects two exchanges 
  2002. in the same country. An international circuit connects two 
  2003. international exchanges situated in different countries. (Based on
  2004. Recommendation\ D.150 and Recommendation\ F.68.)
  2005. .RT
  2006. .sp 1P
  2007. .LP
  2008. A.2
  2009.     \fBcircuit group\fR 
  2010. .sp 9p
  2011. .RT
  2012. .PP
  2013. The set of all switched circuits which directly interconnect one exchange 
  2014. with another. 
  2015. .RT
  2016. .sp 1P
  2017. .LP
  2018. A.3
  2019.     \fBcircuit sub\(hygroup\fR 
  2020. .sp 9p
  2021. .RT
  2022. .PP
  2023. A set of circuits within a circuit group which are uniquely
  2024. identifiable for operational or technical reasons. A circuit group may 
  2025. consist of one or more circuit sub\(hygroups. 
  2026. .RT
  2027. .sp 1P
  2028. .LP
  2029. A.4
  2030.     \fBdestination\fR 
  2031. .sp 9p
  2032. .RT
  2033. .PP
  2034. A country in which the called subscriber is located or an area or other 
  2035. location that may be specified within that country. A destination can be 
  2036. identified by the digits used for routing the call. 
  2037. .RT
  2038. .sp 1P
  2039. .LP
  2040. A.5
  2041.     \fBbid\fR 
  2042. .sp 9p
  2043. .RT
  2044. .PP
  2045. An attempt to obtain a circuit in a circuit group or to a
  2046. destination. A bid may be successful or unsuccessful in seizing a circuit in
  2047. that circuit group or to that destination.
  2048. .RT
  2049. .sp 1P
  2050. .LP
  2051. A.6
  2052.     \fBseizure\fR 
  2053. .sp 9p
  2054. .RT
  2055. .PP
  2056. A seizure is a bid for a circuit in a circuit group which succeeds in obtaining 
  2057. a circuit in that circuit group. 
  2058. .RT
  2059. .sp 1P
  2060. .LP
  2061. A.7
  2062.     \fBanswer signal\fR 
  2063. .sp 9p
  2064. .RT
  2065. .PP
  2066. A signal sent in the backward direction indicating that the call is answered. 
  2067. (Based on Recommendation\ Q.254.) 
  2068. .RT
  2069. .sp 1P
  2070. .LP
  2071. A.8
  2072.     \fBholding time\fR 
  2073. .sp 9p
  2074. .RT
  2075. .PP
  2076. The time interval between seizure and release of a circuit or
  2077. switching equipment.
  2078. .RT
  2079. .sp 1P
  2080. .LP
  2081. A.9
  2082.     \fBbusy\(hyflash signal (sent in the backward direction)\fR 
  2083. .sp 9p
  2084. .RT
  2085. .PP
  2086. This signal is sent to the outgoing international exchange to show that 
  2087. either the circuit group, or the called subscriber, is busy 
  2088. (Signalling Systems\ No.\ 4 and No.\ 5, see Recommendations\ Q.120 and\ Q.140).
  2089. .PP
  2090. \fINote\fR \ \(em\ In Signalling Systems No. 6 and No. 7, there is no busy\(hyflash 
  2091. signal. However, the equivalent of busy\(hyflash can be roughly approximated 
  2092. through the aggregation of specific backward failure signals such as circuit
  2093. group congestion, national network congestion and subscriber busy.
  2094. .bp
  2095. .RT
  2096. .sp 2P
  2097. .LP
  2098. \fBRecommendation\ E.412\fR 
  2099. .RT
  2100. .sp 2P
  2101. .sp 1P
  2102. .ce 1000
  2103. \fBNETWORK\ MANAGEMENT\ CONTROLS\fR 
  2104. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.412''
  2105. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.412    %'
  2106. .ce 0
  2107. .sp 1P
  2108. .LP
  2109. \fB1\fR     \fBIntroduction\fR 
  2110. .sp 1P
  2111. .RT
  2112. .PP
  2113. 1.1
  2114. Network management controls provide the means to alter the
  2115. flow
  2116. of traffic in the network in support of the network management objectives 
  2117. given in Recommendation\ E.410. Most network management controls are taken 
  2118. by or 
  2119. in the exchange (see Recommendation\ Q.542), but certain actions can be taken
  2120. external to the exchange. This Recommendation provides specific information 
  2121. on network management controls and gives guidance concerning their application. 
  2122. However, it should be noted that the suggested use for each network management 
  2123. control is given only for the purpose of illustration. Other controls, 
  2124. separately or in combination, may be more appropriate in any given situation.
  2125. .sp 1P
  2126. .RT
  2127. .PP
  2128. 1.2
  2129. The application or removal of network management controls
  2130. should be based on network performance data which indicates that action is   
  2131. .LP
  2132. required in accordance with the network management principles in
  2133. Recommendation\ E.410, \(sc\ 4. Performance data will also measure the 
  2134. effect of any network management control taken, and will indicate when 
  2135. a network management control should be modified or removed (see Recommendations\ 
  2136. E.411 and\ E.502). 
  2137. .PP
  2138. 1.3
  2139. Controls can be activated or removed in an exchange by input
  2140. from a network management operations system or by direct input from a terminal. 
  2141. In some cases, controls can be activated automatically either by external 
  2142. or 
  2143. internal stimulus, or when a parameter threshold has been exceeded. [The
  2144. automatic congestion control (ACC) system is an example (see \(sc\ 4.1).] When
  2145. automatic control operation is provided, means for human override should 
  2146. also be provided. 
  2147. .sp 2P
  2148. .LP
  2149. \fB2\fR     \fBTraffic to be controlled\fR 
  2150. .sp 1P
  2151. .RT
  2152. .sp 1P
  2153. .LP
  2154. 2.1
  2155.     \fIType of traffic\fR 
  2156. .sp 9p
  2157. .RT
  2158. .PP
  2159. Exchanges should be capable of applying a range of network
  2160. management controls (see Recommendation\ Q.542). For increased flexibility 
  2161. and precision, there is considerable advantage when the effect of a control 
  2162. can be limited to a particular specified traffic element. 
  2163. .PP
  2164. The operating parameters of a control can be defined by a set of
  2165. traffic attributes. As shown in Figure\ 1/E.412, these parameters include
  2166. distinctions based on the origin of the traffic, for example customer\(hydialled, 
  2167. operator\(hydialled, transit or other such classification as may be specified 
  2168. by the Administration. These can be further classified by type of service, 
  2169. particularly for ISDN.
  2170. .RT
  2171. .LP
  2172. .rs
  2173. .sp 15P
  2174. .ad r
  2175. \fBFigure 1/E.412, p.\fR 
  2176. .sp 1P
  2177. .RT
  2178. .ad b
  2179. .RT
  2180. .LP
  2181. .bp
  2182. .PP
  2183. Additional attributes can be specified based on information which may be 
  2184. available in the exchange. For example, incoming/outgoing circuit group 
  2185. class, or hard\(hyto\(hyreach status of destinations (see \(sc\ 2.2) can 
  2186. be used. Further distinctions can be based on the outgoing traffic type, 
  2187. for example direct 
  2188. routed, alternate routed or transit.
  2189. .PP
  2190. In general, the more attributes that can be specified for a control, the 
  2191. more precise will be its effect. 
  2192. .PP
  2193. \fINote\fR \ \(em\ Precision is of vital importance, particularly in the 
  2194. case of protective controls. 
  2195. .RT
  2196. .sp 2P
  2197. .LP
  2198. 2.2
  2199.     \fIHard\(hyto\(hyreach (HTR) process\fR 
  2200. .sp 1P
  2201. .RT
  2202. .PP
  2203. 2.2.1
  2204. A hard\(hyto\(hyreach process for network management will enable
  2205. exchanges to automatically make more efficient use of network resources 
  2206. during periods of network congestion by improving the performance of network 
  2207. management controls. This improved performance is derived from the ability 
  2208. to distinguish between destinations that are easy to reach (ETR) and 
  2209. destinations that are hard\(hyto\(hyreach (HTR), (e.g.,\ destinations with 
  2210. a low 
  2211. answer bid ratio) and applying heavier controls to HTR traffic. This
  2212. distinction can be based on:
  2213. .sp 9p
  2214. .RT
  2215. .LP
  2216.     i)
  2217.     internal performance measurements within the exchange
  2218. and/or the network management operations system;
  2219. .LP
  2220.     ii)
  2221.     similar information gathered and reported by other
  2222. exchanges;
  2223. .LP
  2224.     iii)
  2225.     historical and current observations of network performance
  2226. by network managers.
  2227. .LP
  2228. .PP
  2229. The network manager should have the ability to set the threshold for HTR 
  2230. determination in the exchange or network management operations system, 
  2231. and to assign a destination as HTR regardless of its actual status. 
  2232. .sp 1P
  2233. .LP
  2234. 2.2.2
  2235.     \fIControlling traffic based on HTR status\fR 
  2236. .sp 9p
  2237. .RT
  2238. .PP
  2239. When a call to a destination that is on the HTR list is being
  2240. routed and a network management control on HTR
  2241. traffic is encountered, the call should be controlled according to the
  2242. relevant parameters. If a destination is considered HTR, it normally
  2243. should be HTR for all outgoing circuit groups.
  2244. .PP
  2245. Additional details of the hard\(hyto\(hyreach process can be found in
  2246. Recommendation\ Q.542.
  2247. .RT
  2248. .sp 2P
  2249. .LP
  2250. 2.3
  2251.     \fIMethods for specifying the amount of traffic to be controlled\fR 
  2252. .sp 1P
  2253. .RT
  2254. .sp 1P
  2255. .LP
  2256. 2.3.1
  2257.     \fICall percentage control\fR 
  2258. .sp 9p
  2259. .RT
  2260. .PP
  2261. There is considerable advantage when exchange controls can be
  2262. activated to affect a variable percentage of traffic (for example\ 10%, 25%,
  2263. 50%, 75% or\ 100%).
  2264. .RT
  2265. .sp 1P
  2266. .LP
  2267. 2.3.2
  2268.     \fICall rate control\fR 
  2269. .sp 9p
  2270. .RT
  2271. .LP
  2272. .PP
  2273. An ability to set an upper limit on the maximum number of calls to be allowed 
  2274. to access the network during a specified period of time is of 
  2275. particular advantage.
  2276. .RT
  2277. .sp 2P
  2278. .LP
  2279. \fB3\fR     \fBExchange controls\fR 
  2280. .sp 1P
  2281. .RT
  2282. .PP
  2283. Network management controls may be applied in exchanges to control traffic 
  2284. volume or to control the routing of traffic. The resulting effect on 
  2285. traffic of these controls may be expansive or protective, depending on the
  2286. control used, its point of application and the traffic element selected for
  2287. control.
  2288. .RT
  2289. .sp 1P
  2290. .LP
  2291. 3.1
  2292.     \fITraffic volume controls\fR 
  2293. .sp 9p
  2294. .RT
  2295. .PP
  2296. Traffic volume controls generally serve to control the volume of
  2297. traffic offered to a circuit group or destination. These include the
  2298. following:
  2299. .bp
  2300. .RT
  2301. .sp 2P
  2302. .LP
  2303. 3.1.1
  2304.     \fIDestination controls\fR 
  2305. .sp 1P
  2306. .RT
  2307. .sp 1P
  2308. .LP
  2309. 3.1.1.1
  2310.     \fICode blocking\fR 
  2311. .sp 9p
  2312. .RT
  2313. .PP
  2314. This control bars routing for a specific destination on a
  2315. percentage basis. Code blocking can be done on a country code, an area code, 
  2316. .PP
  2317. an exchange identifying code or an individual line number. The last of 
  2318. these is the most selective control available. 
  2319. .RT
  2320. .LP
  2321.     \fITypical\ application:\fR  | Used for immediate control of focussed
  2322. overloads or mass\(hycalling situations.
  2323. .sp 1P
  2324. .LP
  2325. 3.1.1.2
  2326.     \fICall\(hygapping\fR 
  2327. .sp 9p
  2328. .RT
  2329. .PP
  2330. This control sets an upper limit on the number of call attempts
  2331. allowed to be routed to the specified destination in a particular period of
  2332. time (for example, no more than 5\ call attempts per minute). Thus, the 
  2333. number of call attempts that are routed can never exceed the specified 
  2334. amount. 
  2335. .RT
  2336. .LP
  2337.     \fITypical\ application:\fR  | Used for the control of focussed
  2338. overloads,
  2339. particularly mass\(hycalling to an individual line number. A detailed
  2340. analysis may be required to determine the proper call\(hyrate
  2341. parameters.
  2342. .sp 1P
  2343. .LP
  2344. 3.1.2
  2345.     \fICancellation of direct routing\fR 
  2346. .sp 9p
  2347. .RT
  2348. .PP
  2349. This control blocks the amount of direct routed traffic accessing a circuit 
  2350. group. 
  2351. .RT
  2352. .LP
  2353.     \fITypical\ application:\fR  | Used to reduce traffic to congested
  2354. circuit
  2355. groups or exchanges where there is no alternate routed traffic.
  2356. .sp 1P
  2357. .LP
  2358. 3.1.3
  2359.     \fICircuit directionalization\fR 
  2360. .sp 9p
  2361. .RT
  2362. .PP
  2363. This control changes both\(hyway operated circuits to incoming
  2364. operated circuits, either on a percentage basis or by a specified number of
  2365. circuits. At the end of the circuit group for which access is inhibited, 
  2366. this is a protective action, whereas at the other end of the circuit group 
  2367. (where 
  2368. access is still available), it is an expansive action.
  2369. .RT
  2370. .LP
  2371.     \fITypical\ application:\fR  | To enhance the flow of traffic outward
  2372. from
  2373. a disaster area while inhibiting incoming traffic.  To have an effect,
  2374. it is recommended that the minimum amount of directionalization be at
  2375. least\ 50%.
  2376. .sp 1P
  2377. .LP
  2378. 3.1.4
  2379.     \fICircuit turndown/busying/blocking\fR 
  2380. .sp 9p
  2381. .RT
  2382. .PP
  2383. This control removes one\(hyway and/or both\(hyway operated circuits from 
  2384. service, either on a percentage basis or by a specified number of 
  2385. circuits.
  2386. .RT
  2387. .LP
  2388.     \fITypical\ application:\fR  | Used to control exchange congestion when
  2389. no other control action is available.
  2390. .sp 1P
  2391. .LP
  2392. 3.1.5
  2393.     \fISpecialized volume controls\fR 
  2394. .sp 9p
  2395. .RT
  2396. .PP
  2397. Both the automatic congestion control (ACC) system and the
  2398. selective circuit reservation control (SCR) are volume controls, but due 
  2399. to their specialized nature, they are described separately in \(sc\ 4.1 
  2400. and 
  2401. \(sc\ 4.2.
  2402. .RT
  2403. .sp 1P
  2404. .LP
  2405. 3.2
  2406.     \fIRouting control\fR 
  2407. .sp 9p
  2408. .RT
  2409. .PP
  2410. Routing controls are used to control the routing of traffic to a
  2411. destination, or to or from a circuit group. However, it should be noted that
  2412. in some cases a routing control may also affect the volume of traffic. 
  2413. Controls which are applied to circuit groups may also be applied to circuit 
  2414. sub\(hygroups, when appropriate. 
  2415. .RT
  2416. .sp 1P
  2417. .LP
  2418. 3.2.1
  2419.     \fICancellation of alternative routing\fR 
  2420. .sp 9p
  2421. .RT
  2422. .PP
  2423. Two versions of this control are possible. One version prevents
  2424. traffic from overflowing \fIFROM\fR  | the controlled circuit group: alternative 
  2425. routing from (ARF). The other version prevents overflow traffic from all
  2426. sources from having access \fITO\fR the controlled circuit group: alternative
  2427. routing to (ART). See Figure\ 2/E.412.
  2428. .RT
  2429. .LP
  2430.     \fITypical\ application:\fR  | There are many uses for this control.
  2431. These include controlling alternative routing in a congested network
  2432. to limit multi\(hylink connections, or to reduce alternative routed
  2433. attempts on a congested exchange.
  2434. .bp
  2435. .LP
  2436. .rs
  2437. .sp 24P
  2438. .ad r
  2439. \fBFigure 2/E.412, p.\fR 
  2440. .sp 1P
  2441. .RT
  2442. .ad b
  2443. .RT
  2444. .sp 1P
  2445. .LP
  2446. 3.2.2
  2447.     \fISkip\fR 
  2448. .sp 9p
  2449. .RT
  2450. .PP
  2451. This control allows traffic to bypass a specified circuit group
  2452. and advance instead to the next circuit group in its normal routing
  2453. pattern.
  2454. .RT
  2455. .LP
  2456.     \fITypical\ application:\fR  | Used to bypass a congested circuit group
  2457. or distant exchange when the next circuit group can deliver the call
  2458. attempts to the destination without involving the congested circuit
  2459. group or exchange. Application is usually limited to networks with
  2460. extensive alternative routing. When used on both\(hyway circuit groups
  2461. it has an expansive effect on traffic flow in the opposite direction.
  2462. .sp 1P
  2463. .LP
  2464. 3.2.3
  2465.     \fITemporary alternative routing\fR 
  2466. .sp 9p
  2467. .RT
  2468. .PP
  2469. This control redirects traffic from congested circuit groups to
  2470. other circuit groups not normally available which have idle capacity
  2471. at the time.
  2472. .RT
  2473. .LP
  2474.     \fITypical\ application:\fR  | To increase the number of successful calls
  2475. during periods of circuit group congestion and to improve the grade of
  2476. service to subscribers.
  2477. .sp 1P
  2478. .LP
  2479. 3.2.4
  2480.     \fISpecial recorded announcements\fR 
  2481. .sp 9p
  2482. .RT
  2483. .PP
  2484. These are recorded announcements which give special information to operators 
  2485. and/or subscribers, such as to defer their call to a later time. 
  2486. .RT
  2487. .LP
  2488.     \fITypical\ application:\fR  | Used to notify customers of unusual
  2489. network
  2490. conditions, and to modify the calling behavior of customers and
  2491. operators when unusual network conditions are present. Calls that are
  2492. blocked by other network management controls can also be routed to a
  2493. recorded announcement.
  2494. .bp
  2495. .LP
  2496. .rs
  2497. .sp 25P
  2498. .ad r
  2499. \fBFigure 3/E.412, p.\fR 
  2500. .sp 1P
  2501. .RT
  2502. .ad b
  2503. .RT
  2504. .sp 2P
  2505. .LP
  2506. \fB4\fR     \fBAutomatic exchange controls\fR 
  2507. .sp 1P
  2508. .RT
  2509. .PP
  2510. Automatic dynamic network management controls
  2511. represent a significant improvement over conventional controls. These controls, 
  2512. which are preassigned, can quickly respond to conditions internally detected 
  2513. by the 
  2514. exchange, or to status signals from other exchanges, and are promptly removed 
  2515. when no longer required. Automatic control applications should be planned, 
  2516. taking into account the internal overload control strategy provided in the
  2517. exchange software.
  2518. .RT
  2519. .sp 2P
  2520. .LP
  2521. 4.1
  2522.     \fIAutomatic congestion control system\fR 
  2523. .sp 1P
  2524. .RT
  2525. .sp 1P
  2526. .LP
  2527. 4.1.1
  2528.     \fIExchange congestion\fR 
  2529. .sp 9p
  2530. .RT
  2531. .PP
  2532. When a digital international/transit exchange carries traffic
  2533. above the engineered level, it can experience an overload that
  2534. diminishes its total call processing capability. Because of
  2535. the speed of the onset of such congestion and the critical nature of the
  2536. condition, it is appropriate that control be automatic. The automatic
  2537. congestion control (ACC) system consists in the congested exchange sending a
  2538. congestion indicator to the connected exchange(s) using common channel
  2539. signalling. The exchange(s) receiving the congestion indication can respond  
  2540. .PP
  2541. by reducing a certain percentage of the traffic offered to the congested
  2542. exchange, based on the response action selected for each application.
  2543. .RT
  2544. .sp 1P
  2545. .LP
  2546. 4.1.2
  2547.     \fIDetection and transmission of congestion status\fR 
  2548. .sp 9p
  2549. .RT
  2550. .PP
  2551. An exchange should establish a critical operating system benchmark, and 
  2552. when continued levels of nominal performance are not achieved (e.g.\ due 
  2553. to excessive traffic), a state of congestion is declared. Thresholds should 
  2554. be 
  2555. established so that the two levels of congestion can be identified, with
  2556. congestion level\ 2 (CL2) indicating a more severe performance degradation
  2557. than congestion level\ 1 (CL1). When either level of congestion occurs, the
  2558. exchange should have the capability to:
  2559. .RT
  2560. .LP
  2561.     1)
  2562.     code an ACC indication in the appropriate
  2563. common channel signalling messages, and
  2564. .LP
  2565.     2)
  2566.     notify its network management
  2567. centre and support system of a change in its current congestion status.
  2568. .bp
  2569. .sp 1P
  2570. .LP
  2571. 4.1.3
  2572.     \fIReception and control\fR 
  2573. .sp 9p
  2574. .RT
  2575. .PP
  2576. When an exchange receives a signal that indicates a congestion
  2577. problem at a connected exchange, the receiving exchange should have the
  2578. capability to reduce the number of seizures sent to the congested exchange.
  2579. .PP
  2580. An exchange should have the capability of:
  2581. .RT
  2582. .LP
  2583.     1)
  2584.     assigning an ACC
  2585. response action on an individual circuit group
  2586. .FS
  2587. In this context, the
  2588. .LP
  2589. term \*Qcircuit group\*U refers to all of the outgoing and both\(hyway circuit
  2590. sub\(hygroups which may directly connect the congested exchange and the 
  2591. responding exchange. 
  2592. .FE
  2593. basis, as specified by the network manager, and
  2594. .LP
  2595.     2)
  2596.      notifying its network management centre and support system of a change 
  2597. in congestion status received from a distant exchange. 
  2598. .PP
  2599. There should be several control categories available in the
  2600. exchange.  Each category would specify the type and amount of traffic to be
  2601. controlled in response to each of the received ACC\ indicators. The categories 
  2602. could be structured so as to present a wide range of response options. 
  2603. .PP
  2604. For a specific ACC response category, if the received ACC indicator is 
  2605. set to a CL1 condition then the receiving exchange could, for example, 
  2606. control a percentage of the Alternate Routed To (ART) traffic to the affected 
  2607. exchange. The action taken by the control would be to either SKIP or CANCEL 
  2608. the 
  2609. controlled calls, depending on the ACC\ response action that was assigned to
  2610. that circuit group. In a similar manner, if a CL2 condition is indicated, 
  2611. then the receiving exchange could control all ART traffic and some percentage 
  2612. of 
  2613. Direct Routed\ (DR) traffic. Other options could include the ability to
  2614. control hard\(hyto\(hyreach traffic, or transit traffic. In the future, control
  2615. categories 
  2616. .PP
  2617. could be expanded to include service\(hyspecific controls. This would be
  2618. particularly useful in the transition to ISDN.
  2619. .PP
  2620. \fINote\fR \ \(em\ ACC response categories can be set locally in the exchange 
  2621. or by input from a network management centre, or operations system. 
  2622. .PP
  2623. Table 1/E.412 is an example of the flexibility that could be achieved in 
  2624. response to a signal from an exchange that is experiencing congestion. 
  2625. In 
  2626. this example, different control actions would be taken based upon the
  2627. distinction between ART and DR\ traffic types. These actions could represent 
  2628. the initial capabilities available with the ACC control. Other alternatives 
  2629. in the future could include the ability to control hard\(hyto\(hyreach 
  2630. traffic (see \(sc\ 2.2), or transit traffic or to provide other controls 
  2631. such as call\(hygapping. 
  2632. Additional response categories could also be added to Table\ 1/E.412 to give
  2633. greater flexibility and more response options to the ACC control. It could 
  2634. also be possible to exclude priority calls from ACC control. 
  2635. .RT
  2636. .ce
  2637. \fBH.T. [T1.412]\fR 
  2638. .ce
  2639. TABLE\ 1/E.412
  2640. .ce
  2641. \fBACC control response\fR 
  2642. .ps 9
  2643. .vs 11
  2644. .nr VS 11
  2645. .nr PS 9
  2646. .TS
  2647. center box;
  2648. cw(60p) | cw(60p) | cw(30p) sw(30p) sw(30p) , ^  | ^  | c | c | c.
  2649. Congestion level    Traffic type    Response category
  2650.         A    B    C
  2651. _
  2652. .T&
  2653. cw(60p) | cw(60p) | cw(30p) | cw(30p) | cw(30p) , ^  | c | c | c | c.
  2654. CL1    ART    \ \ 0    \ \ 0    100
  2655.     DR    \ \ 0    \ \ 0    \ \ 0
  2656. _
  2657. .T&
  2658. cw(60p) | cw(60p) | cw(30p) | cw(30p) | cw(30p) , ^  | c | c | c | c.
  2659. CL2    ART    100    100    100
  2660.     DR    \ \ 0    \ 75    \ 75
  2661. _
  2662. .TE
  2663. .nr PS 9
  2664. .RT
  2665. .ad r
  2666. \fBTable 1/E.412 [T1.412], p.\fR 
  2667. .sp 1P
  2668. .RT
  2669. .ad b
  2670. .RT
  2671. .LP
  2672. .bp
  2673. .PP
  2674. 4.1.4
  2675. Any international application of ACC should be based on
  2676. negotiation and bilateral agreement among the affected Administrations. This
  2677. includes an agreement as to whether the controlled calls should be skipped 
  2678. or cancelled. Application within a national network would be a national 
  2679. matter. An exchange that is capable of \*QACC receive and control\*U should 
  2680. not 
  2681. indiscriminately assign ACC to all routes since a distant exchange may be
  2682. equipped for common channel signalling, but may not yet have an ACC transmit
  2683. capability. This could result in invalid information in the ACC fields 
  2684. in the signalling messages and the inappropriate application of ACC controls 
  2685. at the 
  2686. receiving exchange. Additional details on the ACC\ system are in
  2687. Recommendation\ Q.542.
  2688. .sp 9p
  2689. .RT
  2690. .sp 2P
  2691. .LP
  2692. 4.2
  2693.     \fISelective circuit reservation control\fR 
  2694. .sp 1P
  2695. .RT
  2696. .PP
  2697. 4.2.1
  2698. The selective circuit reservation control enables an exchange to automatically 
  2699. give preference to a specific type (or types) of traffic over others (e.g.,\ 
  2700. direct routed calls over alternate routed calls) at the moment 
  2701. when circuit congestion is present or imminent. The selective circuit
  2702. reservation control can be provided with one or two thresholds, with the  
  2703. .sp 9p
  2704. .RT
  2705. .LP
  2706. latter being preferred due to its greater selectivity. Specific details 
  2707. on the selective circuit reservation control may be found in 
  2708. Recommendation\ Q.542.
  2709. .sp 1P
  2710. .LP
  2711. 4.2.2
  2712.     \fIGeneral characteristics\fR 
  2713. .sp 9p
  2714. .RT
  2715. .PP
  2716. The selective circuit reservation control has the following
  2717. operating parameters:
  2718. .RT
  2719. .LP
  2720.     \(em
  2721.     a reservation threshold(s),
  2722. .LP
  2723.     \(em
  2724.     a control response,
  2725. .LP
  2726.     \(em
  2727.     a control action option.
  2728. .PP
  2729. The reservation threshold defines how many circuits or how much
  2730. circuit capacity should be reserved for those traffic types to be given
  2731. preferred access to the circuit group. The control response defines which
  2732. traffic types should be given a lesser preference in accessing the circuit
  2733. group, and the quantity of each type of traffic to control. The control 
  2734. action option defines how those calls denied access to the circuit group 
  2735. should be 
  2736. handled. The control action options for processing of calls denied access to
  2737. the circuit group may be SKIP or CANCEL.
  2738. .PP
  2739. When the number of idle circuits or the idle capacity in the
  2740. given circuit group is less than or equal to the reservation threshold, the
  2741. exchange would check the specified control response to determine if calls
  2742. should be controlled. The SKIP response allows a call to alternate\(hyroute 
  2743. to the next circuit group in the routing pattern (if any) while the CANCEL 
  2744. response 
  2745. blocks the call.
  2746. .PP
  2747. These parameters should be able to be set locally in the exchange for each 
  2748. selected circuit group or by input from a network management operations 
  2749. system. In addition, the network manager should have the capability to 
  2750. enable and disable the control, and to enable the control but place it 
  2751. in a state 
  2752. where the control does not activate (e.g.,\ by setting the reservation 
  2753. threshold to zero). Further, the network manager should have the ability 
  2754. to set the 
  2755. values for the response categories.
  2756. .RT
  2757. .sp 1P
  2758. .LP
  2759. 4.2.3
  2760.     \fISingle threshold selective circuit reservation control\fR 
  2761. .sp 9p
  2762. .RT
  2763. .PP
  2764. In this version of the control, only a single reservation threshold would 
  2765. be available for the specified circuit group. 
  2766. .PP
  2767. Table 2/E.412 is an example of the flexibility that could be achieved in 
  2768. the control's response to circuit group congestion. In the future, other 
  2769. .PP
  2770. distinctions between traffic could be identified that would expand the 
  2771. number of traffic types in Table\ 2/E.412. An example would be to control 
  2772. hard\(hyto\(hyreach traffic as indicated in \(sc\ 2.2, or to give preference 
  2773. to priority calls. 
  2774. .RT
  2775. .sp 1P
  2776. .LP
  2777. 4.2.4
  2778.     \fIMulti\(hythreshold selective circuit reservation control\fR 
  2779. .sp 9p
  2780. .RT
  2781. .PP
  2782. The multi\(hythreshold control provides two reservation thresholds for 
  2783. the specified circuit group. The purpose of multiple reservation thresholds 
  2784. is to allow a gradual increase in the severity of the control response 
  2785. as the 
  2786. number of idle circuits in the circuit group decreases. The only restriction 
  2787. on the assignment of reservation thresholds would be that a reservation 
  2788. threshold associated with a more stringent control must always be less 
  2789. than or equal to the reservation threshold of any less stringent control, 
  2790. in terms of the number of reserved circuits, or circuit capacity. 
  2791. .bp
  2792. .RT
  2793. .ce
  2794. \fBH.T. [T2.412]\fR 
  2795. .ce
  2796. TABLE\ 2/E.412
  2797. .ce
  2798. \fBAn example of a single threshold selective circuit reservation\fR 
  2799. .ce
  2800. \fBPercentage control response table\fR 
  2801. .ps 9
  2802. .vs 11
  2803. .nr VS 11
  2804. .nr PS 9
  2805. .TS
  2806. center box;
  2807. cw(60p) | cw(60p) | cw(30p) sw(30p) sw(30p) , ^  | ^  | c | c | c.
  2808.  {
  2809. Circuit group
  2810. reservation threshold
  2811.  }    Traffic type     {
  2812. Response category assigned to circuit group
  2813.  }
  2814.         A    B    C
  2815. _
  2816. .T&
  2817. cw(60p) | cw(60p) | cw(30p) | cw(30p) | cw(30p) , ^  | c | c | c | c.
  2818. RT1    ART    25    50    100
  2819.     DR    \ 0    \ 0    \ 25
  2820. _
  2821. .TE
  2822. .nr PS 9
  2823. .RT
  2824. .ad r
  2825. \fBTable 2/E.412 [T2.412], p.\fR 
  2826. .sp 1P
  2827. .RT
  2828. .ad b
  2829. .RT
  2830. .PP
  2831. Table 3/E.412 is an example of the flexibility that could be achieved in 
  2832. the control's response to circuit group congestion with a two\(hyreservation 
  2833. threshold control. In the future, other distinctions between traffic could 
  2834. be identified that would expand the number of traffic types in Table\ 3/E.412. 
  2835. An example would be to control hard\(hyto\(hyreach traffic as indicated 
  2836. in \(sc\ 2.2. 
  2837. .RT
  2838. .ce
  2839. \fBH.T. [T3.412]\fR 
  2840. .ce
  2841. TABLE\ 3/E.412
  2842. .ce
  2843. \fBAn example of a two\(hythreshold selective circuit reservation\fR 
  2844. .ce
  2845. \fBPercentage control response table\fR 
  2846. .ps 9
  2847. .vs 11
  2848. .nr VS 11
  2849. .nr PS 9
  2850. .TS
  2851. center box;
  2852. cw(54p) | cw(54p) | cw(24p) sw(24p) sw(24p) sw(24p) sw(24p) , ^  | ^  | c | c | c | c | c.
  2853.  {
  2854. Circuit group
  2855. reservation threshold
  2856.  }    Traffic type     {
  2857. Response category assigned to circuit group
  2858.  }
  2859.         A    B    C    D    E
  2860. _
  2861. .T&
  2862. cw(54p) | cw(54p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) , ^  | c | c | c | c | c | c.
  2863. RT1    ART    25    50    75    100    100
  2864.     DR    \ 0    \ 0    \ 0    \ \ 0    \ \ 0
  2865. _
  2866. .T&
  2867. cw(54p) | cw(54p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) , ^  | c | c | c | c | c | c.
  2868. RT2    ART    50    75    75    100    100
  2869.     DR    \ 0    \ 0    25    \ 50    100
  2870. _
  2871. .TE
  2872. .nr PS 9
  2873. .RT
  2874. .ad r
  2875. \fBTable 3/E.412 [T3.412], p.\fR 
  2876. .sp 1P
  2877. .RT
  2878. .ad b
  2879. .RT
  2880. .sp 2P
  2881. .LP
  2882. \fB5\fR     \fBStatus and\fR \fBavailability of network management controls\fR 
  2883. .sp 1P
  2884. .RT
  2885. .PP
  2886. 5.1
  2887. The exchange and/or network management operations systems
  2888. should provide information to the network management centre and/or the 
  2889. exchange staff as to what controls are currently active and whether the 
  2890. controls were 
  2891. activated automatically or by human intervenion. Measurements of calls 
  2892. affected by each control should also be available (see Recommendation\ 
  2893. E.502). 
  2894. .sp 9p
  2895. .RT
  2896. .PP
  2897. 5.2
  2898. To help insure the viability of network management
  2899. functions during periods of exchange congestion, network management terminals 
  2900. .LP
  2901. (or exchange interfaces with network management operations systems), and
  2902. functions such as controls, should be afforded a high priority in the exchange 
  2903. operating software. 
  2904. .bp
  2905. .sp 2P
  2906. .LP
  2907. \fB6\fR     \fBOperator controls\fR 
  2908. .sp 1P
  2909. .RT
  2910. .PP
  2911. Traffic operators are usually aware of problems as they occur in
  2912. the network, and this information can reveal the need to control traffic. 
  2913. The operators can then be directed to modify their normal procedures to 
  2914. reduce 
  2915. repeated attempts (in general, or only to specified destinations), or to use
  2916. alternative routings to a destination. They can also provide information to
  2917. customers and distant operators during unusual situations, and can be provided 
  2918. with special call handling procedures for emergency calls. 
  2919. .RT
  2920. .sp 2P
  2921. .LP
  2922. \fBRecommendation E.413\fR 
  2923. .RT
  2924. .sp 2P
  2925. .sp 1P
  2926. .ce 1000
  2927. \fBINTERNATIONAL\ NETWORK\ MANAGEMENT\ \(em\ PLANNING\fR 
  2928. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.413''
  2929. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.413    %'
  2930. .ce 0
  2931. .sp 1P
  2932. .LP
  2933. \fB1\fR     \fBIntroduction\fR 
  2934. .sp 1P
  2935. .RT
  2936. .PP
  2937. 1.1
  2938. Many situations arise which may result in abnormally high or unusually 
  2939. distributed traffic levels in the international network, or loss of network 
  2940. capacity, or both. These situations include the following: 
  2941. .sp 1P
  2942. .RT
  2943. .LP
  2944.     \(em
  2945.     peak calling days,
  2946. .LP
  2947.     \(em
  2948.     failure of transmission systems (including planned outages),
  2949. .LP
  2950.     \(em
  2951.     failure of exchanges,
  2952. .LP
  2953.     \(em
  2954.     failure of common channel signalling systems,
  2955. .LP
  2956.     \(em
  2957.     mass\(hycalling situations,
  2958. .LP
  2959.     \(em
  2960.     disasters,
  2961. .LP
  2962.     \(em
  2963.     introduction of new services.
  2964. .LP
  2965. .PP
  2966. Experience has shown that advanced planning for these situations has a 
  2967. beneficial effect on overall network management efficiency and 
  2968. effectiveness. The timely application of planned control strategies can be
  2969. instrumental in improving network performance.
  2970. .PP
  2971. 1.2
  2972. For known or predictable events, predetermined network
  2973. management plans should be developed and agreed between Administrations,
  2974. bearing in mind the costs involved. The degree of detail of any plan will
  2975. depend on the type of situation to be covered. For example, a recurring 
  2976. event such as Christmas or New Year's Day may be planned in great detail. 
  2977. The lack of real\(hytime network management facilities in an Administration 
  2978. should not 
  2979. preclude planning activities.
  2980. .PP
  2981. 1.3
  2982. When unforeseen situations arise for which predetermined plans do not exist, 
  2983. ad hoc arrangements will need to be agreed at the time. Whether 
  2984. network management actions result from a negotiated plan, or an ad\ hoc
  2985. arrangement, it is essential that agreement be reached between Administrations 
  2986. concerned before such actions are actually implemented. 
  2987. .PP
  2988. 1.4
  2989. Network management planning is normally performed by the \*Qnetwork management 
  2990. planning and liaison\*U point (see Recommendation\ E.414). 
  2991. .LP
  2992. .PP
  2993. 1.5
  2994. Another aspect of network management planning is long\(hyrange
  2995. planning for the development and introduction of new network management
  2996. techniques and capabilities for surveillance and control. This includes the
  2997. development of new or improved controls which may be necessary due to the
  2998. introduction of new services or the transition to ISDN. These functions are
  2999. normally performed by the \*Qnetwork management development\*U point
  3000. (see Recommendation\ E.414).
  3001. .sp 2P
  3002. .LP
  3003. \fB2\fR     \fBDevelopment of plans\fR 
  3004. .sp 1P
  3005. .RT
  3006. .PP
  3007. 2.1
  3008. A comprehensive 
  3009. network management plan
  3010. would include   some or all of the following, as appropriate:
  3011. .sp 9p
  3012. .RT
  3013. .LP
  3014.     \(em
  3015.     Key indicators or criteria which should be used to decide
  3016. when a plan should be implemented.
  3017. .LP
  3018.     \(em
  3019.     The identification of destinations or points likely to be
  3020. affected, along with an assessment as to the likely impact on
  3021. originating and/or terminating traffic.
  3022. .LP
  3023.     \(em
  3024.     Control actions which may be required or that should be
  3025. considered locally and in distant locations. This includes the
  3026. identification of temporary alternative routings which may be
  3027. available for use, and the modifications to automatic controls
  3028. which may be necessary.
  3029. .bp
  3030. .LP
  3031.     \(em
  3032.      Special call handling procedures to be used by operators, and notification 
  3033. requirements. 
  3034. .LP
  3035.     \(em
  3036.      Communication requirements. This includes identification of the necessary 
  3037. information flows between the network management 
  3038. centre and other organizations which may be involved or may have
  3039. information concerning the problem (such as maintenance and
  3040. operator centres).
  3041. .LP
  3042.     \(em
  3043.     Data requirements. This includes determining what
  3044. information may be relevant and where it is available.
  3045. .LP
  3046.     \(em
  3047.     Key events or milestones. These are critical elements which
  3048. can measure the success or progress of a plan, and indicate when
  3049. certain actions should begin or end.
  3050. .PP
  3051. 2.2
  3052. Regardless of the format or detail in a plan, it will not be
  3053. fully effective unless it is readily available and understood by all who 
  3054. may be involved including other Administrations. This requires that network 
  3055. management plans be reviewed on a regular basis. 
  3056. Plans should be reviewed to ensure that they
  3057. reflect changes or additions that may have taken place in the network since 
  3058. the plan was prepared. This is particularly important for plans which are 
  3059. used 
  3060. .LP
  3061. infrequently. Attention should be directed to changes in routing, the
  3062. introduction of new circuit groups, new exchanges or common channel signalling, 
  3063. or the addition of new network management capabilities since the plan was 
  3064. first developed. 
  3065. .PP
  3066. 2.3
  3067. When developing network management plans, it is important that
  3068. they be flexible and, if possible, contain a number of alternatives. This is
  3069. necessary because a planned action may not be viable or available at a given
  3070. time, for example:
  3071. .LP
  3072.     \(em
  3073.     it may be under consideration for the same or another
  3074. problem,
  3075. .LP
  3076.     \(em
  3077.     it may already be in use for some other purpose,
  3078. .LP
  3079.     \(em
  3080.     a planned transit point may not be available due to
  3081. congestion or a lack of spare capacity to or from the transit point
  3082. at the time.
  3083. .sp 2P
  3084. .LP
  3085. \fB3\fR     \fBPeak day planning\fR 
  3086. .sp 1P
  3087. .RT
  3088. .PP
  3089. 3.1
  3090. There are a number of days which give rise to heavy calling in the international 
  3091. network. These usually correspond to certain religious or 
  3092. national
  3093. holidays. Plans should be developed for those holidays which have resulted,
  3094. or are expected to result, in unusually heavy traffic.
  3095. .sp 9p
  3096. .RT
  3097. .LP
  3098. .PP
  3099. Peak\(hyday calling
  3100. can result in significant and sustained blockages in the network. This 
  3101. can be caused by two factors: 
  3102. .LP
  3103.     \(em
  3104.     the average length of conversation on a peak day in many
  3105. cases can be significantly longer than on a normal business day;
  3106. .LP
  3107.     \(em
  3108.      the calling pattern (which is usually residential in nature) may be different 
  3109. than the normal pattern (which is usually 
  3110. business\(hyoriented).
  3111. .PP
  3112. A combination of these factors can result in a
  3113. network that is highly congested and which requires careful planning and
  3114. extensive network management controls to optimize service and revenues.
  3115. .PP
  3116. It should be noted that many peak calling days may also be public
  3117. holidays. As a result, staffing in telephone exchanges and administrative
  3118. offices may be minimal and some traffic data and service measurements may 
  3119. not be readily available. These factors should also be considered in peak\(hyday 
  3120. planning.
  3121. .RT
  3122. .PP
  3123. 3.2
  3124. Peak\(hyday plans may include information on the following, as
  3125. appropriate:
  3126. .LP
  3127.     \(em
  3128.      Network management staffing requirements and expected hours of operations, 
  3129. and the exchange of such information with other 
  3130. network management centres.
  3131. .LP
  3132.     \(em
  3133.     Provision of temporary additional circuits.
  3134. .LP
  3135.     \(em
  3136.     Directionalization of both\(hyway circuits where appropriate.
  3137. .LP
  3138.     \(em
  3139.     Temporary alternative routings to take advantage of
  3140. anticipated idle capacity.
  3141. .LP
  3142.     \(em
  3143.      Controls to inhibit alternate routing via transit points that are expected 
  3144. to be congested. 
  3145. .LP
  3146.     \(em
  3147.     Identification of anticipated hard\(hyto\(hyreach points and
  3148. planned controls to reduce attempts to hard\(hyto\(hyreach points.
  3149. .LP
  3150.     \(em
  3151.     Special calling procedures for operators, including the
  3152. exchange of network status information with operator centres.
  3153. .bp
  3154. .LP
  3155.     \(em
  3156.     Advance testing of new controls, or those infrequently
  3157. used (including the testing of the rerouting to ensure proper operation
  3158. and the ability to complete to a terminating number via the transit point).
  3159. .LP
  3160.     \(em
  3161.     Consideration of limiting installation and maintenance
  3162. activity just prior to the peak day to only essential work in order to
  3163. insure that all available circuits and switching equipment are
  3164. in service.
  3165. .LP
  3166.     \(em
  3167.      Procedures to take into account special situations, such as inter\(hyISC 
  3168. circuit groups, circuit multiplication systems,\ etc. 
  3169. .sp 2P
  3170. .LP
  3171. \fB4\fR     \fBTransmission system failure planning\fR 
  3172. .sp 1P
  3173. .RT
  3174. .PP
  3175. 4.1
  3176. The impact on service of the failure of an international
  3177. transmission system will depend on a number of variables:
  3178. .sp 9p
  3179. .RT
  3180. .LP
  3181.     \(em
  3182.     the size of the failed transmission system and its
  3183. relationship to the total network capacity;
  3184. .LP
  3185.     \(em
  3186.     its loading (the number of channels that are assigned for
  3187. use) (this may change frequently);
  3188. .LP
  3189.     \(em
  3190.      the destinations and/or services assigned to the transmission system 
  3191. and their relationship to their respective totals (this may 
  3192. change frequently);
  3193. .LP
  3194.     \(em
  3195.      the traffic intensity during the period from the onset of a failure until 
  3196. restoration or repair (this can vary significantly); 
  3197. .LP
  3198.     \(em
  3199.     the duration of the failure (this is usually unpredictable);
  3200. .LP
  3201.     \(em
  3202.     the availability of 
  3203. restoration capacity
  3204. (this
  3205. can vary).
  3206. .PP
  3207. Thus, it can be seen that it is difficult, if not impossible, to predict 
  3208. the precise impact on service of a failure at a given point in time. 
  3209. However, recognizing the increasing size and loading of modern transmission
  3210. systems, the impact of a failure on service can often be severe, and as a
  3211. result, significant effort has been expended by Administrations to develop 
  3212. and refine transmission system failure restoration plans. 
  3213. .PP
  3214. Experience has shown that network management actions can also play a significant 
  3215. role in minimizing the adverse impact of failures on service. 
  3216. However, it should be noted that these network management actions will 
  3217. usually complement or enhance a transmission failure restoration plan and 
  3218. do not 
  3219. necessarily supplant the need for such plans. For short duration failures,
  3220. e.g.,\ solar interference on satellites, network management plans may be the
  3221. only viable solution.
  3222. .RT
  3223. .LP
  3224. .PP
  3225. 4.2
  3226. When an international transmission system fails, network
  3227. management and transmission restoration activities should proceed in parallel 
  3228. on a coordinated basis. 
  3229. .LP
  3230.     \(em
  3231.     The network management centre will become aware of the
  3232. impact of a failure on service via its network surveillance capacity;
  3233. in some cases, this will occur before the specific details of the
  3234. failure are known. The network management centre can identify the
  3235. affected routes, destinations and/or services. This information
  3236. will guide the application of network management controls and may
  3237. also be useful to the restoration control point (Recommendation\ M.725)
  3238. in setting priorities for restoration.
  3239. .LP
  3240.     \(em
  3241.      The first response of the network management centre should be to consider 
  3242. the use of temporary alternative routings in order to 
  3243. complete traffic which is being blocked by the failure. In many
  3244. cases, these actions can begin immediately, before the decision
  3245. is made to activate a transmission restoration plan.
  3246. .LP
  3247.     \(em
  3248.     If significant congestion continues despite the expansive
  3249. controls, protective controls should be considered. Emphasis
  3250. should be placed on the identification of destinations that are
  3251. hard\(hyto\(hyreach and the selective reduction of traffic to these
  3252. points so that the remaining network can be used by traffic with
  3253. a higher probability of success.
  3254. .PP
  3255. 4.3
  3256. It is recommended that a network management plan for the
  3257. failure of a major international transmission system should include the
  3258. following, as appropriate:
  3259. .LP
  3260.     \(em
  3261.     identification of destinations or points affected for
  3262. originating and terminating traffic,
  3263. .LP
  3264.     \(em
  3265.     temporary alternative routings which may be utilized to
  3266. bypass the failure, and hours of availability,
  3267. .LP
  3268.     \(em
  3269.     notification lists,
  3270. .LP
  3271.     \(em
  3272.     special call handling procedures for operators,
  3273. .LP
  3274.     \(em
  3275.     controls which may be required in connected networks,
  3276. .LP
  3277.     \(em
  3278.     controls to be requested of distant network management
  3279. centres,
  3280. .LP
  3281.     \(em
  3282.     actions to be taken after fault correction to restore the
  3283. network to its normal configuration,
  3284. .LP
  3285.     \(em
  3286.     special 
  3287. recorded announcements
  3288. to customers, when
  3289. necessary.
  3290. .bp
  3291. .sp 2P
  3292. .LP
  3293. \fB5\fR     \fBInternational \fR \fBexchange failure planning\fR 
  3294. .sp 1P
  3295. .RT
  3296. .PP
  3297. 5.1
  3298. The impact on service of the failure of an international
  3299. exchange will depend on a number of variables, which include:
  3300. .sp 9p
  3301. .RT
  3302. .LP
  3303.     \(em
  3304.     whether there is a single or multiple international
  3305. exchange(s),
  3306. .LP
  3307.     \(em
  3308.      the routing plan and the distribution of circuit groups among the international 
  3309. exchanges, 
  3310. .LP
  3311.     \(em
  3312.     the traffic intensity during the failure,
  3313. .LP
  3314.     \(em
  3315.     the duration of the failure,
  3316. .LP
  3317.     \(em
  3318.     the size (capacity) and the current loading of the failed
  3319. exchange, and its relationship to the total international switching
  3320. capacity.
  3321. .LP
  3322. .PP
  3323. In any case, the failure of an international exchange usually will have 
  3324. a severe impact on service. Network management exchange failure plans can 
  3325. provide considerable benefits during the failure by limiting the spread 
  3326. of 
  3327. congestion to connected exchanges and providing alternative ways of routing
  3328. traffic to bypass the failed exchange.
  3329. .PP
  3330. 5.2
  3331. It is recommended that a network management exchange failure
  3332. plan should include the following information, as appropriate:
  3333. .LP
  3334.     \(em
  3335.     general information about the exchange and its function in
  3336. the network, including diagrams of the normal network configuration
  3337. and the reconfigured network during a failure,
  3338. .LP
  3339.     \(em
  3340.      actions to be taken to verify a total failure of an exchange to differentiate 
  3341. it from certain fault recovery actions in SPC 
  3342. exchanges which may, at first, appear similar,
  3343. .LP
  3344.     \(em
  3345.     notification lists,
  3346. .LP
  3347.     \(em
  3348.     initial control actions to be taken upon verification of
  3349. exchange failure,
  3350. .LP
  3351.     \(em
  3352.     additional control actions to be taken based on the prognosis of the failure,
  3353. .LP
  3354.     \(em
  3355.     controls to be applied within the national network,
  3356. .LP
  3357.     \(em
  3358.     controls to be requested of distant network management
  3359. centres,
  3360. .LP
  3361.     \(em
  3362.     modifications which may be required to automatic controls,
  3363. .LP
  3364.     \(em
  3365.      sequence of control removal when the exchange is restored to normal operation. 
  3366. .PP
  3367. 5.3
  3368. It is recommended that network management exchange failure
  3369. plans be reviewed and up\(hydated whenever a significant change in network
  3370. configuration occurs, or at least annually. A network management exchange
  3371. failure plan should be prepared for a new international exchange before 
  3372. it is introduced into the network. 
  3373. .sp 2P
  3374. .LP
  3375. \fB6\fR     \fBCommon channel signalling (CCS)\fR \fBfailure planning\fR 
  3376. .sp 1P
  3377. .RT
  3378. .PP
  3379. 6.1
  3380. When a failure in the common channel signalling system
  3381. interrupts the flow of traffic, the affected traffic may be diverted by 
  3382. network management controls to other unaffected circuits groups. It is 
  3383. preferable that these actions be planned in advance. These plans should 
  3384. identify the 
  3385. modifications to the automatic CCS flow control responses which may be 
  3386. required in the exchanges to permit the planned actions to be taken [for 
  3387. example, to 
  3388. change the normal programmed response to the receipt of a transfer prohibited 
  3389. signal (TFP)]. 
  3390. .sp 9p
  3391. .RT
  3392. .PP
  3393. 6.2
  3394. It should be noted that, as more of the international network
  3395. converts to common channel signalling, the availability of potential
  3396. alternative routings may become limited, which will increase the need for
  3397. careful planning.
  3398. .sp 2P
  3399. .LP
  3400. \fB7\fR     \fBMass\(hycalling planning\fR 
  3401. .sp 1P
  3402. .RT
  3403. .PP
  3404. 7.1
  3405. Uncontrolled mass\(hycalling has the potential to seriously
  3406. disrupt calling in the network. However, with proper planning, the adverse
  3407. effects of many mass\(hycalling situations may be minimized. The key to 
  3408. success is advance warning and interdepartmental cooperation and planning. 
  3409. .bp
  3410. .sp 9p
  3411. .RT
  3412. .PP
  3413. This requires that the Administration be alert to potential
  3414. mass\(hycalling situations so that the proposed use of the network can be
  3415. evaluated in advance to determine the potential for congestion. When congestion 
  3416. appears likely, alternative serving arrangements may be proposed, which 
  3417. may 
  3418. include the use of network management controls.
  3419. .PP
  3420. 7.2
  3421. With widespread availability of call\(hygapping controls (see
  3422. Recommendation E.412), certain mass\(hycalling applications may be provided
  3423. without harm to the network. The call\(hygap controls can be set at each 
  3424. exchange to limit outgoing calls to only the amount necessary to keep the 
  3425. called lines filled. It must be noted, however, that no mass\(hycalling 
  3426. control strategy can 
  3427. .LP
  3428. prevent originating congestion and dial tone delays in local exchanges if a
  3429. large number of customers simultaneously attempt to dial a service or specific 
  3430. number. 
  3431. .sp 2P
  3432. .LP
  3433. \fB8\fR     \fBDisasters\fR 
  3434. .sp 1P
  3435. .RT
  3436. .PP
  3437. Disasters can be natural (for example, a typhoon, an earthquake)
  3438. or man\(hymade (an airplane or railroad accident). These
  3439. events can result in either damage to network facilities or in an
  3440. extraordinary number of calls, or both. While it is difficult to predict 
  3441. such a disaster, the effects of a disaster on the telephone network can 
  3442. be predicted with some degree of accuracy and plans developed accordingly. 
  3443. These plans 
  3444. should include:
  3445. .RT
  3446. .LP
  3447.     \(em
  3448.     contact and notification lists,
  3449. .LP
  3450.     \(em
  3451.     control actions required locally and/or in other
  3452. Administrations,
  3453. .LP
  3454.     \(em
  3455.     arrangements for additional staffing and extended hours of
  3456. operation.
  3457. .PP
  3458. (See Recommendation E.411, \(sc 6.5.)
  3459. .LP
  3460. .sp 2P
  3461. .LP
  3462. \fB9\fR     \fBPlanning for the \fR \fBintroduction of new services\fR 
  3463. .sp 1P
  3464. .RT
  3465. .PP
  3466. The introduction of new services in the network may result in new or unusual 
  3467. traffic flow characteristics, and/or unusual traffic demand, 
  3468. particularly when there is strong initial interest in the new service.
  3469. Therefore, the potential impact on the network of a new service should be
  3470. evaluated to identify where congestion or deteriorated service might occur, 
  3471. and to identify what special network management surveillance and control 
  3472. capabilities may be required. It is important that this analysis take place
  3473. well in advance of the planned service availability date, so that the necessary 
  3474. modifications to the exchange and/or network management operations system 
  3475. software can be completed in a timely manner. This will help to insure 
  3476. that the necessary surveillance and control capabilities will be available 
  3477. when the new service is introduced. 
  3478. .RT
  3479. .sp 2P
  3480. .LP
  3481. \fB10\fR     \fBNegotiation and coordination\fR 
  3482. .sp 1P
  3483. .RT
  3484. .PP
  3485. 10.1
  3486. Administrations should exchange information concerning their
  3487. network management capabilities as part of the network management planning
  3488. process. Specific plans should be negotiated in advance on a bilateral or
  3489. multilateral basis, as appropriate. Negotiation in advance will allow time 
  3490. to fully consider all aspects of a proposed plan and to resolve areas of 
  3491. concern, and will permit prompt activation when needed. 
  3492. .sp 9p
  3493. .RT
  3494. .LP
  3495. .PP
  3496. 10.2
  3497. The use of any network management plan must be coordinated with
  3498. the involved Administrations at the time of implementation. This will include 
  3499. (as appropriate): 
  3500. .LP
  3501.     \(em
  3502.      determining that planned transit exchange(s) have switching capacity 
  3503. to handle the additional traffic, 
  3504. .LP
  3505.     \(em
  3506.     determining that there is capacity in the circuit group(s)
  3507. between the planned transit point and the destination,
  3508. .LP
  3509.     \(em
  3510.      advising the transit Administration(s) that transit traffic will be present 
  3511. in its circuit groups and exchanges, 
  3512. .LP
  3513.     \(em
  3514.     arranging for the activation of controls at distant
  3515. locations,
  3516. .LP
  3517.     \(em
  3518.     arranging for surveillance of the plan while in effect to
  3519. determine the need to modify the plan.
  3520. .PP
  3521. When the use of a plan is no longer required, all involved
  3522. Administrations should be notified of its discontinuance, so that the network 
  3523. can be restored to its normal configuration. 
  3524. .bp
  3525. .sp 2P
  3526. .LP
  3527. \fBRecommendation E.414\fR 
  3528. .RT
  3529. .sp 2P
  3530. .sp 1P
  3531. .ce 1000
  3532. \fBINTERNATIONAL\ NETWORK\ MANAGEMENT\ \(em\ ORGANIZATION\fR 
  3533. .EF '%    Fascicle\ II.3\ \(em\ Rec.\ E.414''
  3534. .OF '''Fascicle\ II.3\ \(em\ Rec.\ E.414    %'
  3535. .ce 0
  3536. .sp 1P
  3537. .LP
  3538. \fB1\fR     \fBIntroduction\fR 
  3539. .sp 1P
  3540. .RT
  3541. .PP
  3542. The required high degree of cooperation and coordination in
  3543. international network management can best be achieved by efficient and
  3544. effective interworking between international network management organizations 
  3545. in the various countries. This Recommendation specifies the organizational 
  3546. elements necessary for this purpose, and outlines the functions and
  3547. responsibilities of each element.
  3548. .PP
  3549. Only those organizational elements vital to the network management
  3550. development, planning, implementation and control of the international
  3551. network are dealt with in the Recommendation. It is recognized that other
  3552. functions must necessarily be carried out within the network management
  3553. organization, either in support of the functions specified below or in
  3554. connection with the management of the national network.
  3555. .PP
  3556. It is also recognized that Administrations may not wish to assign each 
  3557. element to a separate staff or create a separate organization. Administrations 
  3558. are, therefore, afforded the freedom to organize such functions in a manner 
  3559. which best suits their own situation and the level of development of
  3560. network management.
  3561. .RT
  3562. .LP
  3563. .sp 2P
  3564. .LP
  3565. \fB2\fR     \fBInternational network management \(em organization\fR 
  3566. .sp 1P
  3567. .RT
  3568. .PP
  3569. 2.1
  3570. As far as international cooperation and coordination are
  3571. concerned, network management should be based on an organization comprising 
  3572. the following elements, all of which should exist in each country practicing 
  3573. international network management:
  3574. .sp 9p
  3575. .RT
  3576. .LP
  3577.     a)
  3578.     network management planning and liaison;
  3579. .LP
  3580.     b)
  3581.     network management implementation and control;
  3582. .LP
  3583.     c)
  3584.     network management development.
  3585. .PP
  3586. Each element represents a set of functions and reponsibilities,
  3587. and are further defined in \(sc\(sc\ 3 to\ 5.
  3588. .LP
  3589. .PP
  3590. 2.2
  3591. At the discretion of the Administration concerned, the elements
  3592. defined in \(sc\(sc\ 3 to\ 5 below can be grouped together in a single
  3593. organizational entity, for example, an 
  3594. International Network Management
  3595. Centre
  3596. .
  3597. This is likely to be the most convenient and efficient approach where the 
  3598. level of development and degree of practice of network management is high. 
  3599. Where 
  3600. such an approach is not possible, or is impractical, international network
  3601. management functions could be carried out at locations where related activities 
  3602. are performed. \(sc\ 6 offers specific guidance on the relationship between 
  3603. network management and network maintenance, and includes consideration 
  3604. for the possible combining of organizational elements involved in the two 
  3605. fields of activity. 
  3606. .PP
  3607. 2.3
  3608. Irrespective of which arrangement an Administration
  3609. decides for its international network management organization, it must 
  3610. ensure that the functions and responsibilities of a particular organizational 
  3611. element are not divided between two separate locations. Administrations 
  3612. can 
  3613. then issue a list of contact point information (see \(sc\ 7 for guidance) which
  3614. will give telephone, telex numbers, service hours\ etc. for each element.
  3615. .LP
  3616. .sp 2P
  3617. .LP
  3618. \fB3\fR     \fBNetwork management planning and liaison\fR 
  3619. .sp 1P
  3620. .RT
  3621. .PP
  3622. 3.1
  3623. Network management planning and liaison is an element within
  3624. the international network management organization. It is concerned
  3625. with liaising with other Administrations to develop plans to cater for
  3626. unforeseen high traffic levels and any other situation likely to adversely
  3627. affect the completion of international calls.
  3628. .sp 9p
  3629. .RT
  3630. .PP
  3631. 3.2
  3632. Network management planning and liaison is responsible for the
  3633. following set of functions:
  3634. .LP
  3635.     a)
  3636.     liaising with similar points in other Administrations to
  3637. determine the actions necessary to overcome unforeseen high traffic levels 
  3638. and other situations adversely affecting the completion of international 
  3639. calls; 
  3640. .LP
  3641.     b)
  3642.     producing plans to cater for the abnormal traffic levels
  3643. produced by foreseen national and international events;
  3644. .LP
  3645.     c)
  3646.      liaising with the restoration liaison officer (RLO) within the Administration 
  3647. concerning network management plans for failures and planned outages; 
  3648. .bp
  3649. .LP
  3650.     d)
  3651.     liaising with similar points in other Administrations to
  3652. establish the required actions when plans to overcome abnormal situations
  3653. cannot be implemented;
  3654. .LP
  3655.     e)
  3656.      ensuring that the facilities and network management controls required 
  3657. for the rapid implementation of agreed plans are available and ready for 
  3658. use when required. 
  3659. .sp 2P
  3660. .LP
  3661. \fB4\fR     \fBNetwork management implementation and control\fR 
  3662. .sp 1P
  3663. .RT
  3664. .PP
  3665. 4.1
  3666. Network management implementation and control is an element
  3667. within the international network management organization. It is
  3668. concerned with monitoring the performance and status of the network in real
  3669. time, determining the need for network management action, and, when necessary, 
  3670. implementing and controlling such action. 
  3671. .sp 9p
  3672. .RT
  3673. .PP
  3674. 4.2
  3675. Network management implementation and control is responsible
  3676. for the following set of functions:
  3677. .LP
  3678.     a)
  3679.     monitoring the status and performance of the network;
  3680. .LP
  3681.     b)
  3682.     collecting and analysing network status and performance
  3683. data;
  3684. .LP
  3685.     c)
  3686.     determining the need for the control of traffic as
  3687. indicated by one or more of the following conditions:
  3688. .LP
  3689.     \(em
  3690.     the failure or planned outage of an international or
  3691. national transmission system,
  3692. .LP
  3693.     \(em
  3694.     the failure or planned outage of an international or
  3695. national exchange,
  3696. .LP
  3697.     \(em
  3698.     congestion in an international exchange,
  3699. .LP
  3700.     \(em
  3701.     congestion in a distant network,
  3702. .LP
  3703.     \(em
  3704.     congestion to an international destination,
  3705. .LP
  3706.     \(em
  3707.     heavy traffic caused by an unusual
  3708. situation;
  3709. .LP
  3710.     d)
  3711.      applying or arranging for network management control action, as described 
  3712. in Recommendation\ E.411, and Recommendation\ E.412; 
  3713. .LP
  3714.     e)
  3715.     liaising and cooperating with similar points in other
  3716. Administrations in the application of network management controls;
  3717. .LP
  3718.     f
  3719. )
  3720.     liaising with the 
  3721. fault report point
  3722. (network)
  3723. .FS
  3724. The
  3725. fault report point (network) is a functional element in the general maintenance 
  3726. organization (see Recommendation\ M.716). 
  3727. .FE
  3728. within the Administration concerning the exchange of information available
  3729. at either point;
  3730. .LP
  3731.     g)
  3732.     liaising with the 
  3733. restoration control point
  3734. .FS
  3735. The restoration control point is a functional element in the general maintenance 
  3736. organization (see Recommendation\ M.725).
  3737. .FE
  3738. within the Administration
  3739. concerning failures and planned outages;
  3740. .LP
  3741.     h)
  3742.     disseminating information as appropriate within its own
  3743. Administration concerning network management actions which have been
  3744. taken.
  3745. .sp 2P
  3746. .LP
  3747. \fB5\fR     \fBNetwork management development\fR 
  3748. .sp 1P
  3749. .RT
  3750. .PP
  3751. 5.1
  3752. Network management development is an element within
  3753. the international network management organization. It is concerned
  3754. with the development and introduction of techniques and facilities for the
  3755. purpose of network management surveillance and control at the international
  3756. level, although it may also have similar responsibilities for the national
  3757. network.
  3758. .sp 9p
  3759. .RT
  3760. .PP
  3761. 5.2
  3762. Network management development is responsible for the
  3763. following set of functions:
  3764. .LP
  3765.     a)
  3766.     developing facilities to enable the application of current
  3767. network management techniques;
  3768. .LP
  3769.     b)
  3770.     long range planning for the coordinated introduction of new
  3771. network management techniques and improved network surveillance and controls;
  3772. .LP
  3773.     c)
  3774.     evaluating the effectiveness of current plans, controls and
  3775. strategies with a view to identifying the need for improved controls, control 
  3776. strategies and support systems, particularly those which may be required 
  3777. for 
  3778. new services and the ISDN.
  3779. .bp
  3780. .LP
  3781. .sp 2P
  3782. .LP
  3783. \fB6\fR     \fBCooperation and coordination between network management and
  3784. network maintenance organizations\fR 
  3785. .sp 1P
  3786. .RT
  3787. .PP
  3788. Considerable benefit may be obtained by close cooperation and
  3789. coordination between the network management organization identified in this
  3790. Recommendation and the network maintenance organization identified in the 
  3791. M.700 series of Recommendations. For example, reports of network difficulties 
  3792. received by the fault report point (network) in the maintenance organization
  3793. may assist the network management implementation and control point in
  3794. refining its control action. Similarly, difficulties reported to the fault
  3795. report point (network) may be explained by information already available 
  3796. to the network management implementation and control point. For this reason, 
  3797. and to 
  3798. take into account the particular operating situation and stage of development 
  3799. of network management within an Administration, some of the functional 
  3800. elements identified in this Recommendation may be located with one of the 
  3801. groupings of functional elements of the network maintenance organization 
  3802. as outlined in 
  3803. Recommendation\ M.710.
  3804. .PP
  3805. Where it is advantageous to create a separate international
  3806. management centre containing the elements defined above, care should be 
  3807. taken to ensure that suitable liaison and information flows occur between 
  3808. such a 
  3809. centre and the network maintenance organization.
  3810. .RT
  3811. .sp 2P
  3812. .LP
  3813. \fB7\fR     \fBExchange of contact point information\fR 
  3814. .sp 1P
  3815. .RT
  3816. .PP
  3817. For each of the three organizational elements in \(sc\(sc\ 3 to\ 5 above, 
  3818. Administrations should exchange contact point information. Network management 
  3819. contact points should be exchanged as part of the general exchange of contact 
  3820. point information as specified in Recommendation\ M.93. 
  3821. .RT
  3822. .LP
  3823. .rs
  3824. .sp 34P
  3825. .ad r
  3826. Blanc
  3827. .ad b
  3828. .RT
  3829. .LP
  3830. .bp
  3831.